Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
От | Robert Haas |
---|---|
Тема | Re: PGXS: REGRESS_OPTS=--load-language=plpgsql |
Дата | |
Msg-id | 603c8f071002191151i929ccb1rcabfdf9d1d462e19@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PGXS: REGRESS_OPTS=--load-language=plpgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
|
Список | pgsql-hackers |
On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > David Fetter <david@fetter.org> writes: >> CREATE OR REPLACE LANGUAGE is an even bigger tar pit. >> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php > > The reason that patch got rejected was that it was implementing > CREATE IF NOT EXISTS --- under a false name. The problem with > that is summarized here: > http://archives.postgresql.org/pgsql-patches/2008-03/msg00416.php > > It wouldn't be that hard to implement actual CREATE OR REPLACE > if we decide that's the most useful solution here. The code > would need to be prepared to use heap_update instead of heap_insert, > and to get rid of old dependencies, but there is plenty of precedent > for that. > > The sticking point for me is still whether or not it's really a good > idea for pg_dump to be emitting CREATE OR REPLACE LANGUAGE. It does not > do that for any other object type. On the other hand, we've already > made languages a special case in pg_dump, since it emits the abbreviated > form of CREATE LANGUAGE in most cases rather than trying to duplicate > the existing object definition. Maybe there wouldn't be any bad results > in practice. We have all sorts of crufty hacks in pg_dump and the backend to cope with restoration of older dumps. Compared to some of those, this is going to be cleaner than newfallen snow. IMHO, anyway. ...Robert
В списке pgsql-hackers по дате отправления: