Re: [HACKERS] pg_class.relpartbound definition overly brittle

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] pg_class.relpartbound definition overly brittle
Дата
Msg-id CA+Tgmoay2=6VKUEqwkfhm2oOBhmpWqyx=ZnK3M6zokG1TfKzAA@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] pg_class.relpartbound definition overly brittle  (Mark Dilger <hornschnorter@gmail.com>)
Ответы Re: [HACKERS] pg_class.relpartbound definition overly brittle  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Wed, May 31, 2017 at 3:40 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
> recent changes have introduced the :location field to the partboundspec
> in pg_catalog.pg_class.  This means that if two identical tables with
> identical partitioning scheme are created, but one is done before a change
> to gram.y, and the other after a change to gram.y, the relpartbound fields
> for those two tables could show up as different.
>
> Can we perhaps remove the :location field here?  If not, could somebody
> please defend why this belongs in the catalog entries for the table?  Sorry
> if I am missing something obvious...

Yeah, that probably wasn't a good decision, although calling a
decision might be giving it too much credit.  I think the easiest
thing to do here would be to change transformPartitionBound() to set
result_spec->location to -1, although maybe a better idea would be to
have two different structures -- one that represents the partition
bound specification *before* parse analysis and another that
represents it *after* parse analysis, rather than reusing the same
structure for both.  Then again, maybe making two different node types
for this is overkill.  Not sure.  Opinions?

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



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

Предыдущее
От: Mark Dilger
Дата:
Сообщение: [HACKERS] pg_class.relpartbound definition overly brittle
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Channel binding support for SCRAM-SHA-256