Robert Haas robertmh...@gmail.com writes:
On Feb 20, 2010, at 10:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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,
On Sun, Feb 21, 2010 at 12:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Feb 20, 2010, at 10:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
There is a very clear set of behaviors that CORL ought to have given
the precedents of our other COR commands. If we
Robert Haas robertmh...@gmail.com writes:
Well, I'm a big fan of CREATE OR REPLACE anything so I like the patch
regardless of whether it solves the current problem, but having said
that, I'm not clear on whether it does in fact solve the current
problem. When PL/pgsql is installed by default,
On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Well, I'm a big fan of CREATE OR REPLACE anything so I like the patch
regardless of whether it solves the current problem, but having said
that, I'm not clear on whether it does in
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Feb 20, 2010, at 10:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
Robert Haas robertmh...@gmail.com writes:
On Sun, Feb 21, 2010 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It will be owned by the bootstrap superuser, so the case is exactly
the one that a non-superuser DBA would be faced with.
Or even a superuser other than the bootstrap superuser, no?
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Attached is a draft patch (no doc changes) that implements CREATE OR
REPLACE LANGUAGE
How is pg_migrator affected by this? It always loads the the dump as
the super-user. How will the pg_dump use CREATE OR REPLACE LANGUAGE?
pg_dump
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Attached is a draft patch (no doc changes) that implements CREATE OR
REPLACE LANGUAGE
How is pg_migrator affected by this? It always loads the the dump as
the super-user. How will the pg_dump use CREATE OR
On Thu, Feb 18, 2010 at 01:51:08PM -0800, David Fetter wrote:
Folks,
While hacking on PL/Parrot, I ran across an issue where when trying
to load PL/pgsql, it's done unconditionally and fails. How do we
fix pg_regress to be a little more subtle about this?
For now, and for the archives,
Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Well, that isn't really going to help us in terms of what to do for 9.0.
But the possibility that something like this might happen in future is
one thing that makes me hesitant about extending CREATE LANGUAGE right
now --- the
Bruce Momjian br...@momjian.us writes:
This discussion is sounding very design-ish, which makes me think we
should just leave things unchanged for 9.0 and have external regression
test designers work around this problem in their Makefiles, as Alvaro
suggested.
I would have said that some time
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
This discussion is sounding very design-ish, which makes me think we
should just leave things unchanged for 9.0 and have external regression
test designers work around this problem in their Makefiles, as Alvaro
suggested.
I would
On Feb 20, 2010, at 9:49 AM, Tom Lane wrote:
This discussion is sounding very design-ish, which makes me think we
should just leave things unchanged for 9.0 and have external regression
test designers work around this problem in their Makefiles, as Alvaro
suggested.
I would have said that
David E. Wheeler wrote:
On Feb 20, 2010, at 9:49 AM, Tom Lane wrote:
This discussion is sounding very design-ish, which makes me think we
should just leave things unchanged for 9.0 and have external regression
test designers work around this problem in their Makefiles, as Alvaro
On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote:
There is also the must fix issue with pg_regress.
Why? My pg_regress runs just fine. If you are talking about 3rd party
modules, I suggested conditional Makefile rules.
Because you can either make the simple change to pg_regress that
David E. Wheeler wrote:
On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote:
There is also the must fix issue with pg_regress.
Why? My pg_regress runs just fine. If you are talking about 3rd party
modules, I suggested conditional Makefile rules.
Because you can either make the simple
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I would have said that some time ago, except that I think we have a
must fix issue here: isn't pg_upgrade broken for any database
containing plpgsql? A decent solution for that probably will allow
something to fall out for the regression
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I would have said that some time ago, except that I think we have a
must fix issue here: isn't pg_upgrade broken for any database
containing plpgsql? A decent solution for that probably will allow
something to fall
On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian br...@momjian.us wrote:
David E. Wheeler wrote:
On Feb 20, 2010, at 11:03 AM, Bruce Momjian wrote:
There is also the must fix issue with pg_regress.
Why? My pg_regress runs just fine. If you are talking about 3rd party
modules, I
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian br...@momjian.us wrote:
Well, I was asking why you labeled it must fix rather than should
fix. I am fine with the pg_regress.c change.
Yeah, if it makes life easier for other people, I say we go for it.
On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian br...@momjian.us wrote:
Well, I was asking why you labeled it must fix rather than should
fix. I am fine with the pg_regress.c change.
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that the way to fix this is to have an ugly kluge in
pg_dump and another ugly kluge in pg_regress (and no doubt ugly kluges
elsewhere by the time all the dust settles).
Robert Haas wrote:
On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian br...@momjian.us wrote:
Well, I was asking why you labeled it must fix rather than should
fix. ?I am fine with
Robert Haas wrote:
IMO, the non-ugly kludges are (1) implement CREATE OR REPLACE LANGUAGE
and (2) revert the original patch. Do you want to do one of those
(which?) or do you have another idea?
I thought we seemed to be converging on some agreement on CREATE OR
REPLACE LANGUAGE.
If
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that the way to fix this is to have an ugly kluge in
pg_dump and another ugly kluge in pg_regress (and no doubt ugly kluges
elsewhere by the time all
On Feb 20, 2010, at 5:16 PM, Bruce Momjian wrote:
Robert Haas wrote:
On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian br...@momjian.us
wrote:
Well, I was asking why you labeled it
On Feb 20, 2010, at 15:03, Tom Lane t...@sss.pgh.pa.us wrote:
Well, I'm willing to implement CREATE OR REPLACE LANGUAGE if people
are agreed that that's a reasonable fix. I'm slightly worried about
the restore-could-change-ownership issue, but I think that's much less
likely to cause problems
On Feb 20, 2010, at 15:18, Andrew Dunstan and...@dunslane.net wrote:
I also think we need to state explicitly that module authors can not
expect build files to be version ignorant and always work. Even if
we do something that handles this particular issue, that is likely
to be a happy
David E. Wheeler da...@kineticode.com writes:
Just throwing this out there: would a syntax such as CREATE OF NOT
EXISTS, a complement to DROP IF EXISTS, avoid the permissions issue?
No, it'd just move it to a different place: now you risk breaking
the restored state rather than pre-existing
On Feb 20, 2010, at 3:57 PM, Tom Lane wrote:
And if so, would that be a syntax we'd want to accept in general?
Could the be a CREATE IF NOT EXISTS TABLE?
*Please* go read some of the linked older discussions before you propose
that. I don't want to rehash it yet again.
:-) Was just a
David Christensen da...@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
Tom Lane wrote:
David Christensen da...@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
On Sat, Feb 20, 2010 at 6:42 PM, David Christensen da...@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
Robert Haas robertmh...@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
On Feb 20, 2010, at 10:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@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.
2010/2/19 Tom Lane t...@sss.pgh.pa.us:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
David Fetter da...@fetter.org wrote:
support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
suggested that we special-case PL/pgsql for 9.0 and greater, as it's
in template0, where those
David E. Wheeler wrote:
On Feb 18, 2010, at 8:38 PM, Tom Lane wrote:
The regression test in the core is targeting only its version,
but some external projects have version-independent tests.
I think it's more like are under the fond illusion that their tests are
version-independent.
On Feb 19, 2010, at 5:36 AM, Alvaro Herrera wrote:
Because it's a lot easier for `pg_regress --load-language=plpgsql` to mean
ensure the language is installed than it is for 3rd-party test suites to
detect what version they're being installed against.
Why doesn't the Makefile running the
On Feb 19, 2010, at 7:43 AM, David E. Wheeler wrote:
Usually PGXS loads after setting all the environment variables, though I
suspect that it wouldn't have any side effects to set regress_opts afterward.
Also, there is no MAJORVERSION in earlier versions, so module authors would
have to
On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
David Fetter da...@fetter.org wrote:
support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
suggested that we special-case PL/pgsql for 9.0 and greater, as
On Fri, Feb 19, 2010 at 01:34:46PM -0500, Robert Haas wrote:
On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
David Fetter da...@fetter.org wrote:
support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... Let me point out that
choosing to install plpgsql by default has already broken --single
restore of practically every pg_dump out there. Nobody batted an eye
about that. Why
On Fri, Feb 19, 2010 at 1:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Did we have consensus on exactly what CREATE OR REPLACE LANGUAGE would
do? Particularly in cases where the existing definition doesn't match
pg_pltemplate?
I am of the opinion that any CREATE OR REPLACE command that completes
David Fetter da...@fetter.org writes:
CREATE OR REPLACE LANGUAGE is an even bigger tar pit.
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php
The reason that patch got rejected was that it was implementing
CREATE IF NOT EXISTS --- under a false name. The problem with
that is
Tom Lane t...@sss.pgh.pa.us writes:
Robert Haas robertmh...@gmail.com writes:
I am still of the opinion that changing this was a bad idea for
exactly this reason. We could perhaps ameliorate this problem by
implementing CREATE OR REPLACE for languages and emitting that
instead; then the
Dimitri Fontaine dfonta...@hi-media.com writes:
Not sure how helpful I'll be there, but I can't help placing the
extension's proposal again.
If we had extensions here, plpgsql would be a core maintained extension,
made available by CREATE EXTENSION in the database (which initdb would
do in
On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David Fetter da...@fetter.org writes:
CREATE OR REPLACE LANGUAGE is an even bigger tar pit.
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php
The reason that patch got rejected was that it was implementing
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 19, 2010 at 2:09 PM, Tom Lane t...@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
Tom Lane t...@sss.pgh.pa.us writes:
Well, that isn't really going to help us in terms of what to do for 9.0.
But the possibility that something like this might happen in future is
one thing that makes me hesitant about extending CREATE LANGUAGE right
now --- the more bells and whistles we put
David Fetter da...@fetter.org writes:
While hacking on PL/Parrot, I ran across an issue where when trying to
load PL/pgsql, it's done unconditionally and fails. How do we fix
pg_regress to be a little more subtle about this?
Why exactly would we want it to not fail? Regression tests are not
On Feb 18, 2010, at 3:27 PM, Tom Lane wrote:
While hacking on PL/Parrot, I ran across an issue where when trying to
load PL/pgsql, it's done unconditionally and fails. How do we fix
pg_regress to be a little more subtle about this?
Why exactly would we want it to not fail? Regression
On Thu, Feb 18, 2010 at 06:27:30PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
While hacking on PL/Parrot, I ran across an issue where when
trying to load PL/pgsql, it's done unconditionally and fails. How
do we fix pg_regress to be a little more subtle about this?
Why
David Fetter escreveu:
OK, I know it's late, but having PL/pgsql on by default has caused an
unforeseen need: --require-language.
Why? IMHO pg_regress should be used with the same postgres version it was
built with. So any tests that use --load-language=plpgsql should be fixed.
Besides we
On Fri, Feb 19, 2010 at 12:26:29AM -0200, Euler Taveira de Oliveira wrote:
David Fetter escreveu:
OK, I know it's late, but having PL/pgsql on by default has caused
an unforeseen need: --require-language.
Why? IMHO pg_regress should be used with the same postgres version
it was built
David Fetter da...@fetter.org wrote:
Any external projects will fail on this if they're attempting to
support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
suggested that we special-case PL/pgsql for 9.0 and greater, as it's
in template0, where those tests are based.
+1 for the
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
David Fetter da...@fetter.org wrote:
support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
suggested that we special-case PL/pgsql for 9.0 and greater, as it's
in template0, where those tests are based.
+1 for the CREATE
On Feb 18, 2010, at 8:38 PM, Tom Lane wrote:
The regression test in the core is targeting only its version,
but some external projects have version-independent tests.
I think it's more like are under the fond illusion that their tests are
version-independent. Are we going to back out the
57 matches
Mail list logo
