From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | andrew(at)supernews(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: System vs non-system casts |
Date: | 2005-04-12 17:42:27 |
Message-ID: | 25268.1113327747@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> On Tue, Apr 12, 2005 at 05:04:03PM -0000, Andrew - Supernews wrote:
>> Checking the OID might be sufficient if it were possible to make the OID
>> counter restart at some value known to be greater than any datlastsysoid,
>> rather than restarting at BootstrapOid.
> In fact AFAICT it does start at BootstrapObjectIdData, which is 16384 by
> default.
This line of thought is pretty much a non-starter, because many "system"
objects are created after the initial bootstrap phase, during standalone
backend sessions that are not fundamentally different from ordinary
operations. For instance I don't think we want a solution in which
casts created as part of the information_schema couldn't be marked as
builtins. (Right at the moment there don't seem to be any such casts,
but certainly there might someday be a need for one.)
Alvaro's "pg_cast.castissystem" idea can be made to work with this,
if necessary by brute-force UPDATEs of pg_cast. Playing games with
the values of OIDs can't ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-04-12 20:08:54 | Re: recovery from idiot delete error |
Previous Message | Alvaro Herrera | 2005-04-12 17:12:49 | Re: System vs non-system casts |