Re: pg_class.relpartbound definition overly brittle

> On Jun 1, 2017, at 6:31 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>> When you guys commit changes that impact partitioning, I notice, and change
>> my code to match. But in this case, it seemed to me the change that got
>> committed was not thought through, and it might benefit the community for
>> me to point it out, rather than quietly make my code behave the same as
>> what got committed.
>
> Let me explain the project standards in words of one syllable: user code
> should not examine the contents of node trees. That's what pg_get_expr
> is for. There is not, never has been, and never will be any guarantee
> that we won't whack those structures around in completely arbitrary ways,
> as long as we do a catversion bump along with it.

I have already dealt with this peculiarity and don't care much at this point, but
I think your characterization of my position is inaccurate:

I'm really not talking about examining the contents of node trees. I'm only
talking about comparing two of them for equality, and getting false as an answer,
when they are actually equal. Asking "Is A == B" is not "examining the contents",
it is asking the project supplied comparator function to examine the contents,
which is on par with asking the project supplied pg_get_expr function to do so.
There is currently only one production in gram.y in the public sources that
creates partitions, so you don't notice the relpartbound being dependent on
which grammar production defined the table. I notice, and think it is an odd
thing to encode in the the relpartbound field. Bumping the catversion is irrelevant
if you have two or more different productions in gram.y that give rise to these
field values. Apparently, you don't care. Fine by me. It just seemed to me an
oversight when I first encountered it, rather than something anybody would
intentionally commit to the sources.

Mark Dilger