Re: pl/pgsql feature request: shorthand for argument and local variable references

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pl/pgsql feature request: shorthand for argument and local variable references
Date: 2021-03-28 12:44:51
Message-ID: 65d349aa-cb83-40d2-b773-033f3b2114e4@www.fastmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 28, 2021, at 14:27, Pavel Stehule wrote:
> ne 28. 3. 2021 v 13:49 odesílatel Joel Jacobson <joel(at)compiler(dot)org> napsal:
>> __It would of course be a problem since other plpgsql extensions could be in conflict with such a label,
>> so maybe we could allow creating a new language, "plmycorp", using the same handlers as plpgsql,
>> with the addition of a hard-coded #ROUTINE_LABEL as a part of the language definition,
>> which would then be forbidden to override in function definitions.
>
> There is no technical problem, but if I remember well, the committers don't like configuration settings that globally modify the behaviour. There can be a lot of issues related to recovery from backups or porting to others systems. Personally I understand and I accept it. There should be some press for ensuring some level of compatibility. And can be really unfanny if you cannot read routine from backups because you have "bad" postgres configuration. It can work in your company, but this feature can be used by others, and they can have problems.

I also dislike configuration that modify behaviour, but I don't think that's what I proposed. Creating a new language would not be configuration, it would be part of the dumpable/restorable schema, just like the functions.

/Joel

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message wangsh.fnst@fujitsu.com 2021-03-28 12:53:09 RE: invalid data in file backup_label problem on windows
Previous Message Joel Jacobson 2021-03-28 12:38:44 Re: Idea: Avoid JOINs by using path expressions to follow FKs