ext/pdo_pgsql: Retrieve the memory usage of the query result resource#14260
ext/pdo_pgsql: Retrieve the memory usage of the query result resource#14260KentarouTakeda wants to merge 8 commits intophp:masterfrom
Conversation
a0dee6a to
215ef4a
Compare
215ef4a to
0aaeae6
Compare
| if(stmt->executed) { | ||
| ZVAL_LONG(val, PQresultMemorySize(S->result)); | ||
| } else { | ||
| ZVAL_NULL(val); |
There was a problem hiding this comment.
I do not know if we should emit a PDO exception in this case, @SakiTakamachi what do you think ?
There was a problem hiding this comment.
I think we can throw an exception here, because it's obviously wrong to try to get the size of a result when there is no "result" yet.
There was a problem hiding this comment.
Ah but mainly these are used for debugging purposes?
In that case, throwing an exception might make the method difficult to use.
If it's unexecuted, does it make sense to interpret this as 0 memory allocation and return 0 (or null)?
There was a problem hiding this comment.
IMO, I prefer to throw an exception for incorrect operations.
On the other hand, if you fetchAll() a statement that has not yet been executed, [] is returned. If consistency is our priority, it may be better not to throw exceptions.
In both cases, it doesn't take me much time since I have the modified code at hand as well.
There was a problem hiding this comment.
Rather, it seems like the problem is that fetching an unexecuted result doesn't result in an error....
That's a relic of PDO when exceptions didn't exist, and I don't think it should still be that way if don't take BC into account.
I'll wait for David's opinion.
There was a problem hiding this comment.
Ah, excuse me. This also has a status....
There was a problem hiding this comment.
I added pdo_pgsql_error_stmt_msg in da6b54b.
If we should not emit exception, I think the current code is the best.
There was a problem hiding this comment.
You can even be more informative since you have access to the statement's name.
Note that, with the last changes, your new test is skipped due to the new constant now missing.
There was a problem hiding this comment.
oh I see, it works only if you enable pgsql too (symbol is defined here).
There was a problem hiding this comment.
Thank you for your time! ! !
I fixed:
There was a problem hiding this comment.
You're probably better off putting the constants in a stub for the subclass.
e.g. (firebird):
https://github.com/php/php-src/blob/master/ext/pdo_firebird/pdo_firebird.stub.php
|
I added a stub and generated arginfo in b5769e6 . |
| #ifdef HAVE_PG_RESULT_MEMORY_SIZE | ||
| REGISTER_PDO_CLASS_CONST_LONG("PGSQL_ATTR_RESULT_MEMORY_SIZE", (zend_long)PDO_PGSQL_ATTR_RESULT_MEMORY_SIZE); | ||
| #endif |
There was a problem hiding this comment.
I'm not sure if I should write this down.
The purpose of subclasses is to allow driver specific functionality to be provided in the subclasses.
This statement would mean having the same constants in PDO core, which may go against the subclassing philosophy.
There was a problem hiding this comment.
However, since PDO::getAttribute is not a subclass-specific method, I'm not sure what to do.
| ZVAL_LONG(val, PQresultMemorySize(S->result)); | ||
| } else { | ||
| char *tmp; | ||
| spprintf(&tmp, 0, "statement '%s' has not been executed yet", S->stmt_name); |
There was a problem hiding this comment.
if you re allocating on the heap then you need to free it at some point. If you run your own test you ll see.
|
Looks ok to me overall, I do not think it needs to me made more complicated than it is. As for returning null vs 0, I think null sends stronger message that the usage is wrong which will lead the user to investigate further via the errorinfo. 0 would have been enough in case of exception raised. But that s just me, so @SakiTakamachi feel free to review and merge it when you see fit. |
SakiTakamachi
left a comment
There was a problem hiding this comment.
I've thought again about what's been discussed and agree that the current state looks good.
Regarding whether or not to include constants in pdo core, it seems fine to leave it as it is, i.e. "include" it.
LGMT, There's really just one small nits :)
| --TEST-- | ||
| PDO PgSQL PDOStatement::getAttribute(PDO::PGSQL_ATTR_RESULT_MEMORY_SIZE) | ||
| --EXTENSIONS-- | ||
| pdo |
There was a problem hiding this comment.
This statement is unnecessary because pdo is always loaded when pdo_pgsql is loaded.
|
Your very thorough reviews and valuable advice are greatly appreciated. Thank you both so much. |
This implementation is similar to Pull Request #14214.
I have implemented the same functionality in
PDOStatement, specifically forPdoPgsql.By calling:
You can find out the amount of memory used internally by the client library
libpq.This value was not reflected in the
memory_get_usage()output, so it was not possible to determine until now.PDOStatementdiffers fromPgSql\Resultin that it may represent a statement that has not yet been executed.In this case,
libpqdoes not allocate memory either.Therefore,PDO::PGSQL_ATTR_RESULT_MEMORY_SIZEreturnsnullin such cases.Since this feature did not require an RFC for
ext/pgsql, I am wondering if it is also unnecessary for this implementation. Please let me know if an RFC is needed or if there are any internals discussions required.