Re: Unexpected result from ALTER FUNCTION— looks like a bug - Mailing list pgsql-general

From Bryn Llewellyn
Subject Re: Unexpected result from ALTER FUNCTION— looks like a bug
Date
Msg-id D6E094DF-22F8-4E8A-9A6F-2E475CF94853@yugabyte.com
Whole thread Raw
In response to Re: Re: Unexpected result from ALTER FUNCTION— looks like a bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unexpected result from ALTER FUNCTION— looks like a bug  ("David G. Johnston" <david.g.johnston@gmail.com>)
List 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
representedin 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
"alterfunction" statements (underlining the fact that there are indeed no semantic restrictions). I hardly have to say
thatthe 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
tospend) to work out why. 


pgsql-general by date:

Previous
From: "Thomas, Richard"
Date:
Subject: RE: PostgreSQL 10.20 crashes / Antivirus
Next
From: Adrian Klaver
Date:
Subject: Re: PostgreSQL 10.20 crashes / Antivirus