Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Fetter <david@fetter.org>, Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>, Euler Taveira de Oliveira <euler@timbira.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2010-02-19T20:01:22Z
Lists: 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