Re: About adding a new filed to a struct in primnodes.h

On Wed, Nov 25, 2020 at 11:54 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> writes:
> > On Wed, Nov 25, 2020 at 9:40 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> What exactly would be the value of that?
> >> ...
>
> > I agree with this, but I don't think there is no value in my suggestion
> > unless I missed something. Per my current understanding, the code
> > is too easy to make the datadir incompatible with binary, which requires
> > user to do some extra work and my suggestion is to avoid that and
> > it is the value.
>
> In practice, a major-version upgrade is also going to involve things like
> these:
>
>
Actually I thought if this would be the main reason for this case, now you
confirmed that. Thank you.

> We already sweat a great deal to make user table contents be upwards
> compatible across major versions. I think that trying to take on
> some similar guarantee with respect to system catalog contents would
> serve mostly to waste a lot of developer manpower that can be put to
> much better uses.
>
> Less experienced people know what to do, but real experienced people
know what not to do. Thanks for sharing the background in detail!

Actually I may struggle too much in a case where I port a feature with
node modification into a lower version which I have to consider the
compatible issue. The feature is inline-cte, We added a new field
in CommonTableExpr which is used to hint optimizer if to think about
the "inline" or not. From the porting aspect, the new field will cause
the incompatible issue, however a hint would not. I know porting will
not be a concern of the community, and I would not argue about hints
in this thread, I just share my little experience for reference here.

Thank you in all.

--
Best Regards
Andy Fan