Jonathan Bartlett <[EMAIL PROTECTED]> writes:
>>> If you want a globally unique ID based on OIDs, use the table OID
>>> concatenated with the row OID.
>> Ok, this make sense !
> Are you sure this works after you hit the 4 billion mark?
If you have a unique index on OID on each table for which yo
On Wed, 2003-09-03 at 22:12, Jonathan Bartlett wrote:
> Are you sure this works after you hit the 4 billion mark?
As long as the returened oid is unique on the table in current session !
/BL
---(end of broadcast)---
TIP 4: Don't 'kill -9' the post
> No it don't know anything about the table it insert into. I simply do
> the following :
>
> 1. INSERT data (comming from another layer)
> 2. Get the last oid
> 3. SELECT * FROM the same table where oid = what I just found.
>
> I know absolutly nothing about the table, and I like it this way :-)
On Wednesday 03 September 2003 17:24, Bo Lorentsen wrote:
> On Wed, 2003-09-03 at 16:13, Tom Lane wrote:
> > The reason OIDs shouldn't be considered unique is that there is no
> > mechanism to enforce that they are unique --- unless you make one,
> > that is, create a unique index on OID for a tabl
On Wed, 2003-09-03 at 17:28, Martijn van Oosterhout wrote:
> If you know the OID of a row, PostgreSQL doesn't have a special lookup table
> to find it. That's also why they're not unique; the backend would have to
> scan through every table to find out if the next one is available.
Ahh, thats not
Bo Lorentsen <[EMAIL PROTECTED]> writes:
> > If I were doing it would extract the primary key of each table on startup
> > and then change that one line of code to:
> >
> > os << "SELECT * FROM " << sTable << " WHERE "
> ><< prikey << " = currval('" << sTable << "_" << prikey << "_seq')";
>
On Wed, Sep 03, 2003 at 01:47:01PM +0200, Bo Lorentsen wrote:
> On Wed, 2003-09-03 at 13:19, Martijn van Oosterhout wrote:
> > The only thing you need to know is the name of the primary key field. This
> > many be a problem in a generic layer. If you like you can make a UNIQUE
> > INDEX on the oid
On Wed, Sep 03, 2003 at 08:46:42 -0700,
Dennis Gearon <[EMAIL PROTECTED]> wrote:
> Why is that, anyway, and why should it be?
Because it reduces contention by giving each backend its own pool
of sequence values. But until you call nextval a backend won't
have any values reserved.
--
On Wed, 2003-09-03 at 16:13, Tom Lane wrote:
> The reason OIDs shouldn't be considered unique is that there is no
> mechanism to enforce that they are unique --- unless you make one,
> that is, create a unique index on OID for a table. The system does
> not do that for you since it would be exces
Dennis Gearon <[EMAIL PROTECTED]> writes:
> Oliver Elphick wrote:
>
> >You cannot use currval() until you have used nextval() on the same
> >sequence in the same session.
> Why is that, anyway, and why should it be?
Because that's what currval() does. It doesn't have anything to do
with sequen
The elimination is in concert with the dying of popularity in 'Object
Oriented Databases', right?
Shridhar Daithankar wrote:
On 3 Sep 2003 at 10:27, Malcolm Warren wrote:
To sum up: The Debian migration gzip file declares that oids are not
guaranteed to be unique, issues dire warnings about
Why is that, anyway, and why should it be?
Oliver Elphick wrote:
On Wed, 2003-09-03 at 12:19, Martijn van Oosterhout wrote:
If I were doing it would extract the primary key of each table on startup
and then change that one line of code to:
os << "SELECT * FROM " << sTable << " WHERE "
<< pr
On Wed, Sep 03, 2003 at 01:05:30PM +0200, Malcolm Warren wrote:
> I agree with you about database design and in fact fortunately I don't use
> oids as foreign keys, which I thought unwise. However I have found oids very
> useful as temporary unique references to a record in my programming. If I
On Wed, 2003-09-03 at 13:19, Martijn van Oosterhout wrote:
> But your insert function needs to know something about the table it's
> inserting into. The sequences have quite predicatable names. Besides, you
> can set the name yourself (DCL does this IIRC).
No it don't know anything about the table
On Wed, Sep 03, 2003 at 12:20:42PM +0200, Bo Lorentsen wrote:
> On Wed, 2003-09-03 at 11:38, Shridhar Daithankar wrote:
>
> > Well, what I do is, declare a serate sequence, retrive next available value and
> > explicitly insert it into a integer field. That avoids having to retrieve the
> > late
On Wed, 2003-09-03 at 11:38, Shridhar Daithankar wrote:
> Well, what I do is, declare a serate sequence, retrive next available value and
> explicitly insert it into a integer field. That avoids having to retrieve the
> latest value again.
Yeps, this is what I call an application specific implim
On 3 Sep 2003 at 11:28, Bo Lorentsen wrote:
> On Wed, 2003-09-03 at 11:10, Shridhar Daithankar wrote:
>
> > Yes. It is correct. As of 7.3.x and onwards oids are optional at table creation
> > times. They default to be available for new objects but that is for backwards
> > compatibility I belie
are you doing this in psql?
Or perl, php, or some other?
perl and php both have methods for getting the oid of the last
inserted row (use "$oid = $sth->{'pg_oid_status'};"
in perl and "$oid = pg_GetLastOid($result_id);" in php )
Look at the php documentation, or do 'perldoc DBD::Pg'
to see mor
I use the following technique:
add sequence to the primary key of the table
look up the sequence the primary key
insert a record using (including) the primary key
re-query the newly inserted record using the primary key
Thanks, Michael
-Original Message-
From: David O'F
19 matches
Mail list logo
