Re: Get rid of system attributes in pg_attribute? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Get rid of system attributes in pg_attribute?
Date
Msg-id 17644.1108833423@sss.pgh.pa.us
Whole thread Raw
In response to Re: Get rid of system attributes in pg_attribute?  (Andreas Pflug <pgadmin@pse-consulting.de>)
Responses Re: Get rid of system attributes in pg_attribute?
Re: Get rid of system attributes in pg_attribute?
List pgsql-hackers
Andreas Pflug <pgadmin@pse-consulting.de> writes:
>>> Does anyone know of client code that actually pays attention to
>>> pg_attribute rows with negative attnums?

> Would those columns remain selectable for debugging/maintenance 
> purposes, despite not appearing in system catalogs?

Certainly.  They just wouldn't have entries in pg_attribute.

It occurs to me that without the explicit entries, we could stop
considering the system names to be reserved column names --- that is,
we could allow users to create ordinary columns by these names.
(The procedure for looking up a column name would be to first try in
pg_attribute, and if that failed to check an internal list of system
column names.)  If you did make such a column, then you'd be unable to
get at the system column you'd masked in that particular table.  I'm
unsure offhand if this would be a good thing or bad.  Not having
reserved column names is certainly good, but masking a system column
is something you might regret when you need to debug.  I suppose you
could always rename the conflicting column if so.

Making the system column names un-reserved would be a very good thing
from the point of view of being able to add more.  I've wished for
some time that there were a system column exposing the tuple flags
(t_infomask).  I've not dared to propose adding it because of the
likelihood of breaking people's table definitions, but if the name
needn't be reserved then that objection goes away.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: Get rid of system attributes in pg_attribute?
Next
From: Jürgen Cappel
Date:
Subject: Re: Data loss, vacuum, transaction wrap-around