Thread: sequences
Are there any plans to implement oid-style functionality for sequences, such as returning the nextval in the result tuple somehow? Is it at all possible to implement? That is one very nice thing about using oid instead, is that it comes back in PQoidStatus. I probably won't stop using oids until this is possible (i've got my own restore which "preserves" (i.e. renumbers) oid references) --brett
Brett McCormick wrote: > > Are there any plans to implement oid-style functionality for > sequences, such as returning the nextval in the result tuple somehow? > > Is it at all possible to implement? That is one very nice thing about > using oid instead, is that it comes back in PQoidStatus. I probably > won't stop using oids until this is possible (i've got my own restore > which "preserves" (i.e. renumbers) oid references) Not possible - sequences are just "a gear", user can use more than one sequences in inserts, etc... But we could return PRIMARY KEY of affected tuple if it exists! I kept this feature in mind when thought about removing OID... Comments ? Vadim
> Brett McCormick wrote: > > > > Are there any plans to implement oid-style functionality for > > sequences, such as returning the nextval in the result tuple somehow? > > > > Is it at all possible to implement? That is one very nice thing about > > using oid instead, is that it comes back in PQoidStatus. I probably > > won't stop using oids until this is possible (i've got my own restore > > which "preserves" (i.e. renumbers) oid references) > > Not possible - sequences are just "a gear", user can use more than > one sequences in inserts, etc... > > But we could return PRIMARY KEY of affected tuple if it exists! > I kept this feature in mind when thought about removing OID... > > Comments ? This would be very useful. I never did like the idea of using OID as reference so a way to get the PIMARY KEY would be A GOOD THING(tm). Michael BTW: I could have sworn the first thing I tried was to grant select on the sequence I was using when it complianed about access. > > Vadim > > * Michael J. Rogan, Network Administrator, 905-624-3020 * * Mark IV Industries, F-P Electronics & I.V.H.S. Divisions * * mrogan@fpelectronics.com mrogan@ivhs.com *
Michael J. Rogan wrote: > > > > > But we could return PRIMARY KEY of affected tuple if it exists! > > I kept this feature in mind when thought about removing OID... > > > > Comments ? > > This would be very useful. I never did like the idea of using OID as > reference so a way to get the PIMARY KEY would be A GOOD THING(tm). But we will have to decide how to deal with multi-key PK... Vadim
On Fri, 27 February 1998, at 10:27:07, Vadim B. Mikheev wrote: > Michael J. Rogan wrote: > > > > > > > > But we could return PRIMARY KEY of affected tuple if it exists! > > > I kept this feature in mind when thought about removing OID... > > > > > > Comments ? > > > > This would be very useful. I never did like the idea of using OID as > > reference so a way to get the PIMARY KEY would be A GOOD THING(tm). > > But we will have to decide how to deal with multi-key PK... > > Vadim How is this implemented?
Brett McCormick wrote: > > On Fri, 27 February 1998, at 10:27:07, Vadim B. Mikheev wrote: > > Michael J. Rogan wrote: > > > > > > > > > > > But we could return PRIMARY KEY of affected tuple if it exists! > > > > I kept this feature in mind when thought about removing OID... > > > > > > > > Comments ? > > > > > > This would be very useful. I never did like the idea of using OID as > > > reference so a way to get the PIMARY KEY would be A GOOD THING(tm). > > > > But we will have to decide how to deal with multi-key PK... > > > > Vadim > > How is this implemented? Using multi-key unique btree indices. Vadim