> On May 31, 2017, at 6:32 PM, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>
> On 2017/06/01 4:50, Robert Haas wrote:
>> 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...
>
> I now think it's kind of annoying too, although not exactly unprecedented
> as others have pointed out. As you well might know, the location field in
> the parse node is to position the error cursor at the correct point in the
> erring command text.
I knew about the location field already, but not that it was already occurring
elsewhere in the catalogs. I just never paid attention to any of the columns
that are doing so. Alvaro's criticisms of my complaint were quite informative.
(Thanks, Alvaro.) I think standardizing the location field to -1 at some point
in all such places would be a good idea, though I am not sufficiently qualified
to say if that should be in 10 or 11, nor whether doing so might cause
backwards compatibility issues, nor whether those would be too much cost
to justify the changes.
> By the way, didn't you first have to come across that? The commit
> (80f583ffe93) that introduced location field to partboundspec also bumped
> up the catalog version, so you would have to reinitialize the database
> directory anyway.
I don't have my work in production yet. Each time I merge changes into
my repository, I run "make check-world", and that of course re-initializes
the data directories for the test databases.
Mark Dilger