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: "David E. Wheeler" on 20 Feb 2010 13:40 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 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 test problem too. There is also the "must fix" issue with pg_regress. Thanks, David -- 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 14:03 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 > >> suggested. > > > > 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 test problem too. > > 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. -- 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: Tom Lane on 20 Feb 2010 15:45 Bruce Momjian <bruce(a)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 test problem too. > Uh, well, I added this to pg_dump.c for 9.0: That's a crock that needs to go away ASAP. 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 15:57 Tom Lane wrote: > Bruce Momjian <bruce(a)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 test problem too. > > > Uh, well, I added this to pg_dump.c for 9.0: > > That's a crock that needs to go away ASAP. Well, it works, so you are going to need to explain it. -- 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: Tom Lane on 20 Feb 2010 17:53
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). 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 |