Skip site navigation (1) Skip section navigation (2)

Re: t_self as system column

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: t_self as system column
Date: 2010-07-06 14:08:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
The Enterprise Postgres Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-07-06 14:21:06
Subject: Re: Re: [COMMITTERS] pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.
Previous:From: Robert HaasDate: 2010-07-06 13:45:10
Subject: Re: Bug? Concurrent COMMENT ON and DROP object

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group