Peter Eisentraut <peter_e@gmx.net> writes:
> What I'm trying to say here is that it might be OK to hardcode the
> properties of core languages in the server, because considering that
> the only officially supported way to activate those is
> "createlang" (rather than using SQL), the properties of them are in
> effect already hardcoded, and from the point of view of a user who is
> using createlang, nothing changes.
Please note that one of the benefits of a template catalog is that
createlang will work for everything in the catalog, not only the core
languages.
> For languages that are not shipped
> in the core, we gain pretty much nothing by this approach as currently
> implemented and potentially introduce more problems than we solve
> (e.g., language is compiled in an untrusted way, but template says it's
> trusted; template says language has validator, but user uses old
> version that has none; template points to $libdir, user has it
> installed elsewhere).
These are straw men. We know we have a problem with hard-coded paths in
old dumps. We know we have a problem with missing validators in old
dumps (which will get worse as more languages acquire validators).
And I think that a template is much more likely to prevent than
introduce the sorts of mis-definition problems you suggest --- all of
them can easily happen now from simple user errors, whereas with a
template it would be right every time.
regards, tom lane