From: | Bo Lorentsen <bl(at)netgroup(dot)dk> |
---|---|
To: | shridhar_daithankar(at)persistent(dot)co(dot)in |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Using oids |
Date: | 2003-09-03 10:20:42 |
Message-ID: | 1062584442.7853.64.camel@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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 implimentation, as one
can't do this at a more genral layer (that does not know about your
table layout).
Like having a general function that insert a row and return the newly
inserted row, containing the defaults set by PG. My code contain this
function (http://www.lue.dk/prj/dbc) and I have no way to make this
work if I'm not able to fetch the oid after an insert, in some way.
> I don't know if this is a widespread practice but I find it useful for more
> than one way in the environment in which I program.
You are not the only one recommenting this solution :-)
> I understand. With growing use of 64 bit hardware, 4 billion will be history
> pretty soon.
Agreed !
> However historically oids were assumed to be 32 bit. There could be places
> which unintentionally assumed it as such. Cleaning all those places is pretty
> difficult given the big code base postgresql has.
One day I will try to look after myself, but what does PG do internaly,
when referring to rows in a unique way (lets say in an index) ?
> If you compile postgresql with Oid as 64 bit integer, that will work in most
> cases probably. However it does not guarantee that it will always work. There
> always could be some places which assumed 32 bit data types.
But if convertet to a string type, all involved places would fail, and
no uncertency are involved when fixing it (well, a little too primitive
argument, I know) :-)
> You can request this to be a TODO to hackers. They will decide if this is worth
> having it. Personally I support it the way it is. Optionally available.
I'm not sure, if my skills reach this fare, but thanks for the advice.
And for the rest --- we disagree :-)
> For large table containing billions of rows, Oids add to tuple size and overall
> IO. If you are not using Oids, they become overhead. Ability to turn them off
> is certainly nice..
Yeps, if they really are not nessesary.
/B
From | Date | Subject | |
---|---|---|---|
Next Message | Amin Schoeib | 2003-09-03 10:25:15 | Re: Oracle decode Function in Postgres |
Previous Message | Csaba Nagy | 2003-09-03 10:02:09 | Re: ERROR: PLPGSQL does not exist |
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2003-09-03 10:49:44 | Re: TCP/IP with 7.4 beta2 broken? |
Previous Message | Malcolm Warren | 2003-09-03 09:39:14 | Re: Using oids |