Re: Unexpected result from ALTER FUNCTION— looks like a bug
Bryn Llewellyn <bryn@yugabyte.com>
From: Bryn Llewellyn <bryn@yugabyte.com>
To: Tom Lane PostgreSQL <tgl@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
Julien Rouhaud <rjuju123@gmail.com>,
pgsql-general list <pgsql-general@lists.postgresql.org>
Date: 2022-04-20T17:45:22Z
Lists: pgsql-general
> tgl@sss.pgh.pa.us wrote: > >> david.g.johnston@gmail.com wrote: >> >> Might I suggest the following... > > Actually, the reason proconfig is handled differently is that it's a variable-length field, so it can't be represented in the C struct that we overlay onto the catalog tuple... Thanks to all who responded. Tom also wrote this, earlier: > In any case, Bryn's right, the combination of a SET clause and a PARALLEL clause is implemented incorrectly in AlterFunction. I'm taking what I've read in the responses to mean that the testcase I showed is considered to be evidence of a bug (i.e. there are no semantic restrictions) and that fix(es) are under consideration. I agree that, as long as you know about the bug, it's trivial to achieve your intended effect using two successive "alter function" statements (underlining the fact that there are indeed no semantic restrictions). I hardly have to say that the point is the risk that you silently don't get what you ask for—and might then need a lot of effort (like I had to spend) to work out why.
Commits
-
Fix breakage in AlterFunction().
- f583633bc130 13.7 landed
- 9130f8cbb919 11.16 landed
- 481a99811a41 12.11 landed
- 409bcfda6bd6 10.21 landed
- 344a225cb9d4 15.0 landed
- 08a9e7a8c791 14.3 landed