Re: Unexpected result from ALTER FUNCTION— looks like a bug

From: Bryn Llewellyn <bryn(at)yugabyte(dot)com>
To: Tom Lane PostgreSQL <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Unexpected result from ALTER FUNCTION— looks like a bug
Date: 2022-04-20 17:45:22
Message-ID: D6E094DF-22F8-4E8A-9A6F-2E475CF94853@yugabyte.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:
>
>> david(dot)g(dot)johnston(at)gmail(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2022-04-20 17:54:20 Re: PostgreSQL 10.20 crashes / Antivirus
Previous Message Thomas, Richard 2022-04-20 17:23:57 RE: PostgreSQL 10.20 crashes / Antivirus