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 case the plpgsql is not well > > extendable. The important structures are private. You can do it, but you > > should do a full copy of plpgsql. I don't think so you can reuse handler's > > routines - it is not prepared for it. Unfortunately, the handler expects > > 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.
