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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: elein <elein(at)varlena(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Procedural language definitions (was Re: 8.1 and syntax checking at create time)
Date: 2005-09-02 19:57:44
Message-ID: 17416.1125691064@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-09-02 20:02:08 Re: Remove xmin and cmin from frozen tuples
Previous Message Bruce Momjian 2005-09-02 19:51:15 Re: Remove xmin and cmin from frozen tuples