Updating OID column
Is there a reason for why you can't update the OID column other than that no
one has bothered to code up the support for it?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
"Peter Eisentraut" <peter_e@gmx.net> wrote
Is there a reason for why you can't update the OID column other than that
no
one has bothered to code up the support for it?
AFAIK if two rows are with the same OID, we will think these two rows are
different versions of the same tuple. So if we allow users to change OID
columns, we may encounter some inconsistency.
Regards,
Qingqing
On Mon, Apr 10, 2006 at 04:40:50PM +0800, Qingqing Zhou wrote:
"Peter Eisentraut" <peter_e@gmx.net> wrote
Is there a reason for why you can't update the OID column other than that
no
one has bothered to code up the support for it?
AFAIK if two rows are with the same OID, we will think these two rows are
different versions of the same tuple. So if we allow users to change OID
columns, we may encounter some inconsistency.
Hardly, OIDs are optional anyway these days. We only guarentee that
OIDs will be unique if you have a unique index on them, so I imagine
the only reason it hasn't happened yet is because nobody's coded it.
How about when you select from a table with OIDs that it shows the OID
column? That would be the final step, wouldn't it?
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
tool for doing 5% of the work and then sitting around waiting for someone
else to do the other 95% so you can sue them.
Martijn van Oosterhout <kleptog@svana.org> writes:
On Mon, Apr 10, 2006 at 04:40:50PM +0800, Qingqing Zhou wrote:
AFAIK if two rows are with the same OID, we will think these two rows are
different versions of the same tuple. So if we allow users to change OID
columns, we may encounter some inconsistency.
Hardly, OIDs are optional anyway these days. We only guarentee that
OIDs will be unique if you have a unique index on them, so I imagine
the only reason it hasn't happened yet is because nobody's coded it.
Right. I looked at this awhile back, though, and found multiple places
that would break if you tried it :-( --- mainly assumptions about the
meaning of resno in target lists. (The comments for the TargetEntry
struct give some but not all of the details.) Given that OID is
semi-deprecated anyway these days, it's not clear it's worth fixing.
regards, tom lane
Tom Lane wrote:
Right. I looked at this awhile back, though, and found multiple
places that would break if you tried it :-( --- mainly assumptions
about the meaning of resno in target lists. (The comments for the
TargetEntry struct give some but not all of the details.) Given that
OID is semi-deprecated anyway these days, it's not clear it's worth
fixing.
I came across this while restoring a botched backup. I imported a
schema dump and copied over various data files, adjusted the
transaction IDs, relfilenodes, etc., but the OIDs of the TOAST tables
are stored in the fields, so it seemed that the OIDs of the TOAST table
entries in pg_class would have to be adjusted. I managed to fix up the
few broken references manually in a binary editor, but having OIDs
updatable would have been handy if more TOAST values had needed fixing.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/