On Sun, Mar 28, 2021, at 14:27, Pavel Stehule wrote:
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