Re: Procedural language definitions (was Re: 8.1 and syntax checking at create time)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Procedural language definitions (was Re: 8.1 and syntax checking at create time)
Дата
Msg-id 17416.1125691064@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Procedural language definitions (was Re: 8.1 and syntax  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Procedural language definitions (was Re: 8.1 and syntax  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> I agree with Tom that it should not be done at this stage of beta. But 
> maybe we should look again at the much lower impact suggestion I made 
> when we moved the handlers and validators to pg_catalog, which was to 
> have pg_dump also do that move rather than leave existing handlers in 
> public.

How are you retroactively going to make existing pg_dumps do that?
I think trying to handle this in pg_dump would introduce still more
inconsistency across installations, because on top of the variables
we have already, it'd matter which pg_dump version you used.

I feel the best idea for a non-initdb-forcing solution is to hardwire
the template knowledge into CREATE LANGUAGE for 8.1 (with of course the
intention of doing my full original proposal for 8.2).  With that in
place, the only messiness from loading old dumps is that you would have
handler function definitions in public --- but they wouldn't be used
(the actual languages would rely on handlers in pg_catalog) and could be
dropped easily.

One reason for doing this now rather than later is that if we wait,
in 8.2 we will be having to contend with 8.1 dumps that want to load
handler function definitions into pg_catalog.  That'll be OK as long as
said definitions are correct --- but if we change any of the PL function
properties between now and 8.2, we'll have a self-inflicted problem to
deal with.  (In the PL template approach as I proposed it, any existing
function of the right name is presumed to be the right thing.)  I think
it would be a really good idea if we could get that out of pg_dump again
before 8.1 goes final.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Remove xmin and cmin from frozen tuples
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Remove xmin and cmin from frozen tuples