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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Joel Jacobson <joel(at)compiler(dot)org>
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:27:51
Message-ID: CAFj8pRDAe9ZGk8tXPDRK4sjc_9WsakaPCrojrP+KYk-G=H=K3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ne 28. 3. 2021 v 13:49 odesílatel Joel Jacobson <joel(at)compiler(dot)org> napsal:

> +1
>
> I really like this feature.
>
> Is there a way to avoid having to write the "#ROUTINE_LABEL" for every
> function defined?
>
> I'm thinking if a company writing a lot of plpgsql functions want to
> decide on a company wide hard-coded label to use for all their plpgsql
> functions. Could it be set globally and enforced for the entire code base
> somehow?
>
> 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.

On second hand - it is very easy to write a tool that checks wanted
#ROUTINE_LABEL in every routine.

Regards

Pavel

> /Joel
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2021-03-28 12:38:44 Re: Idea: Avoid JOINs by using path expressions to follow FKs
Previous Message Joel Jacobson 2021-03-28 12:15:42 Re: Idea: Avoid JOINs by using path expressions to follow FKs