Re: PGXS: REGRESS_OPTS=--load-language=plpgsql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Date
Msg-id 8470.1266609682@sss.pgh.pa.us
Whole thread Raw
In response to Re: PGXS: REGRESS_OPTS=--load-language=plpgsql  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

What worries me about it is mainly the prospect that restoring a dump
would silently change ownership and/or permissions of a pre-existing
language.  Maybe we can live with that but it's a bit nervous making.

One thing we could do that would help limit the damage is have pg_dump
only insert OR REPLACE when it's emitting a parameterless CREATE
LANGUAGE, ie, it's already depending on there to be a pg_pltemplate
entry.  This would guarantee that we aren't changing any of the core
properties of the pg_language entry (since, because of the way CREATE
LANGUAGE already works, any pre-existing entry must match the
pg_pltemplate entry).  But there's still ownership and ACL to worry
about.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Next
From: Dimitri Fontaine
Date:
Subject: Re: PGXS: REGRESS_OPTS=--load-language=plpgsql