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
|
Список | 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 по дате отправления: