Re: system catalog pg_rewrite column ev_attr document description problem

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: system catalog pg_rewrite column ev_attr document description problem
Дата
Msg-id 1370710873.86680.YahooMailNeo@web162906.mail.bf1.yahoo.com
обсуждение исходный текст
Ответ на Re: system catalog pg_rewrite column ev_attr document description problem  (Kevin Grittner <kgrittn@ymail.com>)
Ответы Re: system catalog pg_rewrite column ev_attr document description problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Kevin Grittner <kgrittn@ymail.com> wrote:

> I'll leave this alone for a day.  If nobody objects, I will change
> the ruleutils.c code to work with either value (to support
> pg_upgrade) and change the code to set this to zero, for 9.3 and
> forward only.  I will change the 9.3 docs to mention that newly
> created rows will have zero, but that clusters upgraded via
> pg_upgrade may still have some rows containing the old value of -1.
>
> For anyone casually following along without reading the code, it's
> not a bug in the sense that current code ever misbehaves, but the
> value which has been used for ev_attr to indicate "whole table"
> since at least Postgres95 version 1.01 is not consistent with other
> places we set a dummy value in attribute number to indicate "whole
> table".  Since 2002 we have not supported column-level rules, so it
> has just been filled with a constant of -1.  The idea is to change
> the constant to zero -- to make it more consistent so as to reduce
> confusion and the chance of future bugs should we ever decide to
> use the column again.

When I went to make this change, I found over 100 lines of obsolete
code related to this.  Commit 95ef6a344821655ce4d0a74999ac49dd6af6d342
removed the ability to create a rule on a column effective with
7.3, but a lot of code for supporting that was left behind.  It
seems to me that the rewrite area is complicated without carrying
code that's been dead for over a decade.  The first patch removes
the dead weight.  The second patch makes the change suggested by
Tom.  Those carrying forward from beta1 without an initdb will
still see some rows in pg_rewrite with -1, but anyone else will see
zero for this column.

Does anyone see a problem with applying both of these for 9.3?

> If we were a little earlier in the release cycle I would argue that
> if we're going to do anything with this column we should drop it.

Which is exactly what I think we should do as soon as we branch.

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Вложения

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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: UTF-8 encoding problem w/ libpq
Следующее
От: Tom Lane
Дата:
Сообщение: Proposed patch: remove hard-coded limit MAX_ALLOCATED_DESCS