Re: Unexpected result from ALTER FUNCTION— looks like a bug
От | Bryn Llewellyn |
---|---|
Тема | Re: Unexpected result from ALTER FUNCTION— looks like a bug |
Дата | |
Msg-id | D6E094DF-22F8-4E8A-9A6F-2E475CF94853@yugabyte.com обсуждение исходный текст |
Ответ на | Re: Re: Unexpected result from ALTER FUNCTION— looks like a bug (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Unexpected result from ALTER FUNCTION— looks like a bug
|
Список | 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 по дате отправления: