Re: t_self as system column

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: t_self as system column
Дата
Msg-id AANLkTin7ab3GOqViwgR3TlyearhRSDujR9OdyStrduBk@mail.gmail.com
обсуждение исходный текст
Ответ на Re: t_self as system column  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: t_self as system column  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
On Mon, Jul 5, 2010 at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane <tgl@sss.pgh.pa.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Bug? Concurrent COMMENT ON and DROP object
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.