At 11:05 12/07/00 +0200, Jan Wieck wrote:
>Tom Lane wrote:
>>
>> Philip's INSERT ... RETURNING idea could support returning TID and
>> table OID as a special case, and it has the saving grace that it
>> won't affect apps that don't use it...
What sort of syntax would you use to request TID?
> I like that one alot more too. It should be relatively easy
> to add a list of attributes (specified after RETURNING) to
> the querytree.
For you, maybe! If you feel like giving me a list of sources that will get
me into this, that would be great. I've looked through various executor
modules and the parser, but would appreciate any advice you have to offer...
Note: I am not plaaning on *making* changes, just yet. I'm mainly
interested in understanding the suggestions people are making!
> Then send out a regular result set of tuples
> built from the requested attributes of the new tuple (at
> INSERT/UPDATE) or the old one (at DELETE) during the executor
> run.
This sounds like what I want to do.
> Or maybe both and specified as NEW.attname vs.
> OLD.attnam? Then it needs AS too, making the attribute list
> looking like a targetlist restricted to Var nodes.
This also sounds like a cute feature, so long as it fits naturally into the
changes.
> This doesn't require any changes in the FE/BE protocol. And a
> client using this new feature just expects TUPLES_OK instead
> of COMMAND_OK when using the new functionality.
Sounds good.
Thanks everybody for the feedback, I'll try to understand it and then get
back with a revised plan...
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.C.N. 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/
