Обсуждение: 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/ > 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/