Re: pl/pgsql feature request: shorthand for argument and local variable references - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: pl/pgsql feature request: shorthand for argument and local variable references
Date
Msg-id 20210328140437.4kzbcx3dzotgk6rj@nol
Whole thread Raw
In response to Re: pl/pgsql feature request: shorthand for argument and local variable references  ("Joel Jacobson" <joel@compiler.org>)
Responses Re: pl/pgsql feature request: shorthand for argument and local variable references
List pgsql-hackers
On Sun, Mar 28, 2021 at 03:52:35PM +0200, Joel Jacobson wrote:
> On Sun, Mar 28, 2021, at 15:12, Pavel Stehule wrote:
> > Maybe I don't understand your proposal well, I am sorry. Creating your own language should not be hard, but in this
casethe plpgsql is not well extendable. The important structures are private. You can do it, but you should do a full
copyof plpgsql. I don't think so you can reuse handler's routines - it is not prepared for it. Unfortunately, the
handlerexpects only function oid and arguments, and there is not a possibility how to pass any options (if I know). 
 
> 
> Sorry, let me clarify what I mean.
> 
> I mean something along the lines of adding a new nullable column to "pg_language", maybe "lanroutinelabel"?
> All other columns (lanispl, lanpltrusted, lanplcallfoid, laninline, lanvalidator) would reuse the same values as
plpgsql.

It doesn't seem like a good way to handle some customization of existing
language.  It's too specialized and soon people will ask for fields to change
the default behavior of many other things and a default "routine label" may not
make sense in all languages.  If we were to do that we should probably add a
new function that would be called to setup all language specific stuff that
users may want to change.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: [PATCH] Enhancements to pg_stat_statements contrib extension
Next
From: Tom Lane
Date:
Subject: Re: Idea: Avoid JOINs by using path expressions to follow FKs