Re: [PATCH] Magic block for modules
От | Martijn van Oosterhout |
---|---|
Тема | Re: [PATCH] Magic block for modules |
Дата | |
Msg-id | 20060531211150.GJ23169@svana.org обсуждение исходный текст |
Ответ на | Re: [PATCH] Magic block for modules (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
On Wed, May 31, 2006 at 11:14:27AM -0400, Tom Lane wrote: <snip> > ... The other > stuff seems too blue-sky, and I'm not even sure that it's the right > direction to proceed in. Marko seems to be envisioning a future where > an extension module is this binary blob with install/deinstall/etc code > all hardwired into it. I don't like that a bit. I think the current > scheme with separate SQL scripts is a *good* thing, because it makes it > a lot easier for users to tweak the SQL definitions, eg, install the > functions into a non-default schema. Also, I don't have a problem > imagining extension modules that contain no C code, just PL functions > --- so the SQL script needs to be considered the primary piece of the > module, not the shared library. While you do have a good point about non-binary modules, our module handling need some help IMHO. For example, the current hack for CREATE LANGUAGE to fix things caused by old pg_dumps. I think that's the totally wrong approach long term, I think the pg_dump shouldn't be including the CREATE LANGUAGE statement at all, but should be saying something like "INSTALL plpgsql" and pg_restore works out what is needed for that module. The above requires getting a few bits straight: 1. When given the name of an external module, you need to be able to find the SQL commands needed to make it work. 2. You need to be able to tell if something is installed already or not. 3. You need to be able to uninstall it again. Why do we rely on hand-written uninstall scripts when we have a perfectly functional dependancy mechanism that can adequatly track what was added and remove it again on demand. With these in place, upgrades across versions of postgres could become a lot easier. People using tsearch2 now would get only "INSTALL tsearch2" in their dumps and when they upgrade to 8.2 they get the new definitions for tsearch using GIN. No old definitions to confuse people or the database. (Note: I'm not sure if tsearch would be compatable at the query level, but that's not relevent to the point I'm making). We could get straight into discussions of mechanism, but it would be nice to know if people think the above is a worthwhile idea. Have a ncie day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Вложения
В списке pgsql-patches по дате отправления: