Re: pg_config wrongly marked as not parallel safe? - Mailing list pgsql-hackers

On Thu, Nov 29, 2018 at 4:01 PM Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
> > On Thu, Nov 29, 2018 at 3:50 PM Stephen Frost <sfrost@snowman.net> wrote:
> > > I'd suggest you read through the rest of the thread and see my response
> > > to Tom.
> >
> > I already did that.
>
> Great, then it's unclear, to me at least, what you're getting at in your
> response here.

Well, I don't think it was particularly unclear.  You seem to be
attacking Kyotaro-san's position when, in my opinion, he's correct and
you are wrong.  It looks to me like Tom said more or less the same
thing that Kyotaro-san did, just in different words, and you partially
agreed with him, so I don't really know what's going on here, either.

> Just to be clear as to which I was referring to, what I said there was
> that I felt the way we've been operating is striking a good balance and
> that my concern on this thread was that people appeared to be trying to
> move us away from that.  Today, at least, I feel like we are careful and
> that we consider the impact on indexes when we're making changes to
> immutable functions, and that when we do make such changes, they're for
> very good reasons and that we make a note of them in release notes and
> possibly go farther, such as considering if we could check for their
> usage during pg_upgrade.
>
> Do you feel that's overly aggressive and that we shouldn't care about
> the impact of changing immutable functions that could be used in indexes
> across major versions?  I don't get the impression that you do from your
> prior response, but then it doesn't square with the later comments about
> how I'm being carried away and trying to take some principled stand
> against evil, so I admit to being confused.

Generally, I think Andres is wrong to argue that immutability
shouldn't mean *anything* across major versions.  If we can readily
foresee that something is going to change in the future, then we
shouldn't mark it immutable. However:

1. Andres agrees that pg_config() should be marked stable, not
immutable.  If we agree about how the functions we ACTUALLY HAVE
should be marked, it may not be 100% necessary to go on arguing about
what we should do in hypothetical cases.

2. I do not believe that the fact that we have marked something
immutable bars us from changing the behavior of that thing in a new
major release if we decide we don't like the old behavior, as in the
hypothetical 1 + 1 = 3 example I gave before, or the geometric type
behavior Kyotaro-san mentioned, or the ftoi4(INT_MAX) case Tom
mentioned.

2a. Also, while I believe that such changes should be release-noted
like all other changes, I'm not sure we need to do any more than that
unless the change is something that's likely to bite a lot of people.
Since we are unlikely to get 1 + 1 wrong, most of the actual cases
where this sort of thing comes up are going to be corner cases, and
for many users a reindex will be unnecessary even if they pg_upgrade.
 If we make a change that we can foresee is going to cause widespread
breakage, then more vigorous action is appropriate.  *Maybe* it would
be a good idea to somehow mark in the release notes all changes that
might theoretically require a reindex ... but I'm not volunteering to
do the work.

In short, I don't see that there has been any big problem here in the
past, and I don't see anyone making a proposal that would cause a big
problem in the future. There is some mild disagreement about certain
hypothetical situations and corner cases.

Peace,

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