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