Re: Attention PL authors: want to be listed in template table?
От | Peter Eisentraut |
---|---|
Тема | Re: Attention PL authors: want to be listed in template table? |
Дата | |
Msg-id | 200509080122.37994.peter_e@gmx.net обсуждение исходный текст |
Ответ на | Re: Attention PL authors: want to be listed in template table? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Attention PL authors: want to be listed in template table?
|
Список | pgsql-hackers |
Tom Lane wrote: > Now this certainly discriminates against installing PLs outside > $libdir, but I haven't heard any good reason why people would need to > do that. Development, testing, staging, ... > > 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. You keep saying that, but the fact is that most of the non-core PLs will work just fine across several releases, if only because they have some #ifdef's. So, no, you do not need to upgrade your PLs when you upgrade PostgreSQL. You really don't. You just recompile them and put them back in the same place. There are certainly constraints and exceptions, but as a general rule it simply is not the case. If it were, I would not have started this discussion. Taking a step back and considering this "validator" business in a more general context: Basically, the validator is just a property that may or may not be applicable to a C function hidden inside a shared library. We don't know what's in the shared library, so we (currently) have to rely on the meta information in the dump to find out. This is a special case of a more general problem, which is why I mentioned PostGIS earlier. Any "plug-in" will evolve, and if it's just a bit sophisticated it will have fairly tight dependencies on the server version, which is certainly the case for much of the GIS and GiST stuff. So here we have the same problem. The old dump will have the meta-information on the old plug-in version. Under your theory, which is surely true in certain cases, the user will have to upgrade the plug-in at the same time. So the restore of the dump will have the old, now wrong information. I don't suppose hard-coding the PostGIS schema and ignoring special cases of CREATE FUNCTION will be the answer. One might object that these cases -- procedural languages and PostGIS sort of things -- are different, but they are not. The chance that an upgrade of PostgreSQL will require a version upgrade of the plug-in is about the same. Certainly, the number of users of PostGIS and the various GiST modules (FTS et al.) is comparable to, if not higher than that of some of the PLs. So that means two things: 1. The problem is much worse. 2. The problem is really much less bad because external plug-ins, PL or not, are often coded to work with multple server versions. And they should be, because otherwise the work forced upon the development teams to synchronize and the users to figure all that out will grow more than linearly. > In any case, not one of these arguments seems to me to favor the > alternative of preloading definitions into pg_language: That is not the alternative I am proposing. Your template idea, hard-coded even, is just fine for core languages. For non-core languages I am proposing that we simply do nothing because the problem we are solving does not exist, or at least has a wildly different nature. -- Peter Eisentraut http://developer.postgresql.org/~petere/
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: Attention PL authors: want to be listed in template table?
Следующее
От: Tom LaneДата:
Сообщение: Re: Attention PL authors: want to be listed in template table?