From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Attention PL authors: want to be listed in template table? |
Date: | 2005-09-07 19:38:32 |
Message-ID: | 29213.1126121912@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-09-07 19:45:31 | Re: uuid type for postgres |
Previous Message | Alvaro Herrera | 2005-09-07 19:29:53 | Re: [HACKERS] How to determine date / time of last postmaster restart |