Обсуждение: PG_COMMAND_OK oid information required
Hi,
Would it be possible to provide more information in the PGResult object (or rather its associated functions) about operations that don't return a value of PG_RESULT_OK. Specifically, I believe, it would be useful for clients to know the oid's of values being inserted or updated.
That way, if it realizes there are many similar operations to carry out, it would be easier to use PQExecParams. The only way I can see of doing this currently would be to issue a
select <cols to insert>
from table
limit 1
to get the oids, and then prepare the insert statement using the info retrieved from the select. Am I missing something? Would a patch with this change be considered?
Thanks,
Andy Chambers
Would it be possible to provide more information in the PGResult object (or rather its associated functions) about operations that don't return a value of PG_RESULT_OK. Specifically, I believe, it would be useful for clients to know the oid's of values being inserted or updated.
That way, if it realizes there are many similar operations to carry out, it would be easier to use PQExecParams. The only way I can see of doing this currently would be to issue a
select <cols to insert>
from table
limit 1
to get the oids, and then prepare the insert statement using the info retrieved from the select. Am I missing something? Would a patch with this change be considered?
Thanks,
Andy Chambers
Yahoo! Messenger NEW - crystal clear PC to PC calling worldwide with voicemail
Andy Chambers <andychambers2002@yahoo.co.uk> writes:
> Would it be possible to provide more information in the PGResult object (or rather its associated functions) about
operationsthat don't return a value of PG_RESULT_OK. Specifically, I believe, it would be useful for clients to know
theoid's of values being inserted or updated.
Huh? What oids exactly? There's no such thing as PG_RESULT_OK, so
you're far from making yourself clear.
> Would a patch with this change be considered?
If I understand what you are after at all, it would involve a protocol
change, which means the bar is a whole lot higher than "it'd be nice".
regards, tom lane