Re: t_self as system column

On Mon, Jul 5, 2010 at 3:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> At one time I was hoping to get rid of explicit entries in pg_attribute
>>> for system columns, which would negate this concern.  I think we're
>>> stuck with them now, though, because of per-column permissions.
>
>> Because someone might want to grant per-column permissions on those
>> columns?  That seems like an awfully thin reason to keep all that
>> bloat around.  I bet the number of people who have granted per-column
>> permissions on, say, cmax can be counted on one hand - possibly with
>> five fingers left over.
>
> I'd agree with that argument for the most part, but I'm not entirely
> sure about oid, which has some characteristics of a user-data column.
>
> (OTOH, maybe we could allow just oid to retain an explicit pg_attribute
> entry... could be messy though.)

[woops, forgot to reply on-list]

Treating OID as a user-defined column seems reasonable, and probably
not even that messy if we put some appropriate macros in place. I'm
guessing the messy part would be finding all the places that expect to
be consulting a real pg_attribute row and supplying them with a
faked-up one in its place.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company