PGXS: REGRESS_OPTS=--load-language=plpgsql
in [PgSql]
|
Prev: testing cvs HEAD - HS/SR - PANIC: cannot make newWAL entries during recovery
Next: Thread safety and libxml2
From: Tom Lane on 20 Feb 2010 19:59 David Christensen <david(a)endpoint.com> writes: > On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote: >> If you implement #1, why would you have pg_dump issue CREATE OR >> REPLACE LANGUAGE? We don't do the "OR REPLACE" part for any other >> object I can think of, so why would pg_dump do it for languages by >> default? > In what cases would one be able to meaningfully REPLACE a language, > other than to not break when encountering an already installed > language? I'm getting the distinct impression that Bruce didn't read yesterday's portion of this thread... The proposal that I had in mind was to have pg_dump use OR REPLACE only when emitting a parameterless CREATE LANGUAGE. This would guarantee that both the desired new language definition and any pre-existing one that it could replace would be exactly like the pg_pltemplate entry for the language. The only risk is that the restore would force the language's ownership and permissions to be what they'd been in the source database, which might possibly not be desirable. Then again it might be desirable; it's really hard to decide that without a specific scenario in mind. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 20 Feb 2010 20:11 Tom Lane wrote: > David Christensen <david(a)endpoint.com> writes: > > On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote: > >> If you implement #1, why would you have pg_dump issue CREATE OR > >> REPLACE LANGUAGE? We don't do the "OR REPLACE" part for any other > >> object I can think of, so why would pg_dump do it for languages by > >> default? > > > In what cases would one be able to meaningfully REPLACE a language, > > other than to not break when encountering an already installed > > language? > > I'm getting the distinct impression that Bruce didn't read yesterday's > portion of this thread... > > The proposal that I had in mind was to have pg_dump use OR REPLACE > only when emitting a parameterless CREATE LANGUAGE. This would > guarantee that both the desired new language definition and any > pre-existing one that it could replace would be exactly like the > pg_pltemplate entry for the language. The only risk is that the > restore would force the language's ownership and permissions to be > what they'd been in the source database, which might possibly not > be desirable. Then again it might be desirable; it's really hard > to decide that without a specific scenario in mind. Yea, I did read it, but I was just unclear how adding OR REPLACE wasn't just moving the hack to another location, and because there was so much discussion about OR REPLACE, it felt like we were designing the feature, which is something we don't want to be doing now. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 20 Feb 2010 22:38 On Sat, Feb 20, 2010 at 6:42 PM, David Christensen <david(a)endpoint.com> wrote: > In what cases would one be able to meaningfully REPLACE a language, other > than to not break when encountering an already installed language? i.e.., in > which cases would this not invalidate functions already written if you were > changing from trusted to untrusted status or a different call handler, etc. At the risk of being smart, who cares and why is this our problem? This question has been asked before, and I can't really figure out what is behind the asking of it. It is as if someone imagines that you would install plperl and then come along later and change the handlers to, say, the plpython handlers, and then complain that your functions were all broken. But that is obviously stupid, and no one would do it (or if they did, we would laugh at them). I think the most likely use of CREATE OR REPLACE FUNCTION is to avoid an error when creating a language that might already exist. But it doesn't seem like the only possible use. Perhaps you've done an in-place upgrade to version 9.0 and you'd like to add an inline handler, for example. > If there is not a meaningful case for the OR REPLACE, and it is just a > syntactic loophole to allow the errorless recreation of an existing language > and if the parameters for the CREATE LANGUAGE call indicate identical final > state, why aren't we free change change the semantics of CREATE LANGUAGE to > just issue a NOTIFY instead of an error in that case, and only complain if > there are differences in the call handler, trusted status, etc? I guess we could do that, but it's inconsistent with the way we handle other object types, so it doesn't seem as clean to me. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 20 Feb 2010 22:56 Robert Haas <robertmhaas(a)gmail.com> writes: > I think the most likely use of CREATE OR REPLACE [LANGUAGE] is to avoid > an error when creating a language that might already exist. But it > doesn't seem like the only possible use. Perhaps you've done an > in-place upgrade to version 9.0 and you'd like to add an inline > handler, for example. Given the existing semantics of CREATE LANGUAGE, nothing at all would happen when replacing a language that has a pg_pltemplate entry, because that overrides all the command's options. However, I think CORL has potential use for developers working on a non-core language implementation: they could use it to add an inline handler, for example, without losing the function definitions they already have loaded. Admittedly that's a pretty thin use-case. However, I intensely dislike the line of thought that says "let's take shortcuts because nobody is going to use this except for one specific use-case". There is a very clear set of behaviors that CORL ought to have given the precedents of our other COR commands. If we don't make it do things that way then we are going to surprise users, and we are also going to paint ourselves into a corner because we won't be able to fix it later without creating compatibility gotchas. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 20 Feb 2010 23:08
On Feb 20, 2010, at 10:56 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> I think the most likely use of CREATE OR REPLACE [LANGUAGE] is to >> avoid >> an error when creating a language that might already exist. But it >> doesn't seem like the only possible use. Perhaps you've done an >> in-place upgrade to version 9.0 and you'd like to add an inline >> handler, for example. > > Given the existing semantics of CREATE LANGUAGE, nothing at all would > happen when replacing a language that has a pg_pltemplate entry, > because > that overrides all the command's options. However, I think CORL has > potential use for developers working on a non-core language > implementation: they could use it to add an inline handler, for > example, > without losing the function definitions they already have loaded. > > Admittedly that's a pretty thin use-case. However, I intensely > dislike > the line of thought that says "let's take shortcuts because nobody is > going to use this except for one specific use-case". There is a very > clear set of behaviors that CORL ought to have given the precedents of > our other COR commands. If we don't make it do things that way then > we > are going to surprise users, and we are also going to paint ourselves > into a corner because we won't be able to fix it later without > creating > compatibility gotchas. Exactly. I agree completely. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |