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: Robert Haas on 20 Feb 2010 17:58 On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian <bruce(a)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. > > 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). 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? ....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 18:03 Robert Haas <robertmhaas(a)gmail.com> writes: > On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane <tgl(a)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). > 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? 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 than embedding special cases for plpgsql in a pile of places that we'll never find again. 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 18:16 Robert Haas wrote: > On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas(a)gmail.com> writes: > >> On Sat, Feb 20, 2010 at 2:51 PM, Bruce Momjian <bruce(a)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. > > > > 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). > > 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? For #2, if you mean the pg_dump.c plpgsql hack for pg_migrator, that is not an option unless you want to break pg_migrator for 9.0. 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? -- 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: Bruce Momjian on 20 Feb 2010 18:18 Tom Lane wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: > > On Sat, Feb 20, 2010 at 5:53 PM, Tom Lane <tgl(a)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). > > > 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? > > 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 than embedding special cases for plpgsql in a > pile of places that we'll never find again. All binary upgrade code is clearly marked as binary_upgrade (in fact you complained about my marking them more clearly in tqual.c), so I don't think we are going to lose it. I have answered the other questions by replying to Robert Haas. -- 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: Andrew Dunstan on 20 Feb 2010 18:18
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 not, let me add my vote for that. 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 coincidence rather than something that can be expected all the time. People need to expect to have to do version-dependent things. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |