ne 28. 3. 2021 v 14:45 odesÃlatel Joel Jacobson <j...@compiler.org> napsal:
> On Sun, Mar 28, 2021, at 14:27, Pavel Stehule wrote: > > ne 28. 3. 2021 v 13:49 odesÃlatel Joel Jacobson <j...@compiler.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. > 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). Regards Pavel > > /Joel > > > >
