Re: Attention PL authors: want to be listed in template table?
От | Tom Lane |
---|---|
Тема | Re: Attention PL authors: want to be listed in template table? |
Дата | |
Msg-id | 765.1126133198@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Attention PL authors: want to be listed in template table? (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Attention PL authors: want to be listed in template table?
Re: Attention PL authors: want to be listed in template table? |
Список | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > Tom Lane wrote: >> We know we have a problem with hard-coded paths >> in old dumps. > This is irrelevant for non-core languages. If I have PL/foo 1.0 > installed and upgrade from PostgreSQL 8.0 to 8.1, then I have to > manually recompile PL/foo and install the shared library. So manual > intervention is required in any case and no template system of any kind > will help. Certainly you have to install new software, but that is a task exactly equivalent to installing the new version of Postgres itself. The problem being addressed here is fixing wrong information in your pg_dump scripts, and that is just as real for non-core as core PLs. The proposal *will* fix the need for manual intervention while reloading dump data. > Moreover, the hard-coded paths will not be solved by your proposal. On what basis do you assert that? The proposal will replace those paths by "$libdir/plfoo" (or whatever is in the template), which is something we should be able to go forward with indefinitely ... and if we can't, a template update will fix it in some future release. Now this certainly discriminates against installing PLs outside $libdir, but I haven't heard any good reason why people would need to do that. >> We know we have a problem with missing validators in >> old dumps > This is irrelevant for non-core languages. Again, I see no basis for that assertion. It is only true to the extent that non-core languages haven't created validators yet. > If I have PL/foo 1.0 > installed and upgrade from PostgreSQL 8.0 to 8.1, the validator in > PL/foo 1.0 will not magically appear or disappear. As a general rule, PLs have to at least be recompiled to move to a new release of the backend, and usually need some source code tweaking as well. So I think your premise is faulty. You'll need to install the 8.1 version of that PL, and that very possibly will have a validator where none existed before. > ... The information in > the dump is the only accurate information that exists about the > existence of a validator. Except that the information in the dump is likely *not* to be accurate. It tells you the way things were some number of releases ago, and as we've already seen, people frequently propagate their dumps forward across multiple releases --- indeed, one would hope that they'd be able to do so. We need to fix things so that that Just Works in the face of improvements to PLs. > You are assuming that during the > update from PostgreSQL 8.0 to PostgreSQL 8.1 there will also be an > upgrade from PL/foo 1.0 to PL/foo ${latest-at-time-of-8.1-release}, but > there is simply no basis for assuming that. How many of the past major releases have allowed a previous PL to be used without any changes? Hardly any AFAIR, and 8.1 is certainly not far behind the previous ones when it comes to making internal API changes that affect PLs. In any case, not one of these arguments seems to me to favor the alternative of preloading definitions into pg_language: that preloaded definition is going to be just as wrong as the template information, if either one is wrong. Now it's true that a hardwired template table is harder to fix than a system catalog, but we can get rid of the hardwired table at the same cost (viz, a forced initdb) as adding preloaded definitions. I don't see any other advantage to doing it that way. One other response to your point about surprise or lack of it: in my proposal, in a release or so everyone will just be doing "CREATE LANGUAGE foo" and there will be no surprise that the system knows how to fill in the low-level details. The handler functions will be relegated to what they should have been all along: an implementation detail. But I think that having CREATE LANGUAGE alter the permissions of an existing entry would be a permanent security risk; it will never not surprise people, because other forms of CREATE don't do that. regards, tom lane
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Peter EisentrautДата:
Сообщение: Re: Attention PL authors: want to be listed in template table?