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 19 Feb 2010 10:43 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 tests simply avoid adding > --load-language when the version is higher than 9.0? Shouldn't be a > hard test to write. We have $(MAJORVERSION) to help with this. 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 work around that. Basically though, you're asking all third party module authors who depend on plpgsql in their code and/or tests to modify their makefiles and release new versions to work around something that pg_regress could have fixed internally in 1-2 lines of code and be done with it. Best, 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: "David E. Wheeler" on 19 Feb 2010 12:07 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 work around that. > > Basically though, you're asking all third party module authors who depend on plpgsql in their code and/or tests to modify their makefiles and release new versions to work around something that pg_regress could have fixed internally in 1-2 lines of code and be done with it. I'm sure this is bad C and should do a case-insensitive comparison, but this is essentially what I mean: *** a/src/test/regress/pg_regress.c --- b/src/test/regress/pg_regress.c *************** create_database(const char *dbname) *** 1795,1802 **** */ for (sl = loadlanguage; sl != NULL; sl = sl->next) { ! header(_("installing %s"), sl->str); ! psql_command(dbname, "CREATE LANGUAGE \"%s\"", sl->str); } } --- 1795,1804 ---- */ for (sl = loadlanguage; sl != NULL; sl = sl->next) { ! if (sl->str != "plpgsql") { ! header(_("installing %s"), sl->str); ! psql_command(dbname, "CREATE LANGUAGE \"%s\"", sl->str); ! } } } Does that seem unreasonable? Best, 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: Robert Haas on 19 Feb 2010 13:34 On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: >> David Fetter <david(a)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 LANGUAGE IF NOT EXISTS behavior. > >> 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 next incompatible > change we choose to make as soon as somebody notices that it breaks a > third-party test case? I don't think so. 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 are we suddenly so concerned about its effects on > unnamed test suites? 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 command in the dump would be a noop. ....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: David Fetter on 19 Feb 2010 13:40 On Fri, Feb 19, 2010 at 01:34:46PM -0500, Robert Haas wrote: > On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > Takahiro Itagaki <itagaki.takahiro(a)oss.ntt.co.jp> writes: > >> David Fetter <david(a)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 LANGUAGE IF NOT EXISTS behavior. > > > >> 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 next > > incompatible change we choose to make as soon as somebody notices > > that it breaks a third-party test case? �I don't think so. �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 are we suddenly so > > concerned about its effects on unnamed test suites? > > 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 command in the dump would be a noop. CREATE OR REPLACE LANGUAGE is an even bigger tar pit. For example: http://archives.postgresql.org/pgsql-hackers/2009-10/msg00386.php Please find attached a patch which does this check in pg_regress. Cheers, David. -- David Fetter <david(a)fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter(a)gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
From: Tom Lane on 19 Feb 2010 13:44
Robert Haas <robertmhaas(a)gmail.com> writes: > On Thu, Feb 18, 2010 at 11:38 PM, Tom Lane <tgl(a)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 are we suddenly so concerned about its effects on >> unnamed test suites? > 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 command in the dump would be a noop. Not really going to help for existing dumps (nor future dumps made with pre-9.0 pg_dump versions). However, the case that is probably going to be the most pressing is pg_upgrade, which last I heard insists on no errors during the restore (and I think that's a good thing). That uses the new version's pg_dump so a fix involving new syntax would cover it. 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? 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 |