Re: [HACKERS] alternate regression dbs?
Andrew Dunstan wrote: Anyway, see http://archives.postgresql.org/pgsql-patches/2005-05/msg00179.php Sorry for the delay -- I'm on the final stretch of a major project at work. No objections from me. Joe ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] alternate regression dbs?
Andrew Dunstan [EMAIL PROTECTED] writes: Try attached ... season to taste. The bulk of it is changes for dblink which has the dbname hardcoded. There is probably more to be done with the regression stuff, but this and the earlier change give us the low hanging fruit at least, I think. Applied with light editorialization on the makefile variables ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] alternate regression dbs?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Try attached ... season to taste. The bulk of it is changes for dblink which has the dbname hardcoded. Joe, any objections here? Hmm, I can't find the message with the attachment, in my inbox or in the list archives. Can anyone point me to it? Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] alternate regression dbs?
Joe Conway wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Try attached ... season to taste. The bulk of it is changes for dblink which has the dbname hardcoded. Joe, any objections here? Hmm, I can't find the message with the attachment, in my inbox or in the list archives. Can anyone point me to it? my fault - I sent the original to the wrong list - meanwhile, Tom, who was copied on the original, replied to that :-) Anyway, see http://archives.postgresql.org/pgsql-patches/2005-05/msg00179.php cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] alternate regression dbs?
I meant to mention this during previous discussion. Currently the pg_regress script does dbname=regression and then does everything in terms of $dbname. Would there be any value in providing a --dbname=foo parameter so that different regression sets could use their own db? One virtue at least might be that we would not drop the core regression db all the time - having it around can be useful, I think. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] alternate regression dbs?
Andrew Dunstan [EMAIL PROTECTED] writes: Currently the pg_regress script does dbname=regression and then does everything in terms of $dbname. Would there be any value in providing a --dbname=foo parameter so that different regression sets could use their own db? One virtue at least might be that we would not drop the core regression db all the time - having it around can be useful, I think. I'd be in favor of using three such DBs, one for core, PLs, and contrib. (More than that seems like it would clutter the disk a lot.) But I do use the standard regression DB as a handy testbed for a lot of stuff, and it has bothered me in the past that the contrib installcheck wipes it out. Another point in the same general area: it would probably not be hard to support make check as well as make installcheck for the PLs. (The reason it's hard for contrib is that make install doesn't install contrib ... but it does install the PLs.) Is it worth doing it though? The easy implementation would require building a temp install tree for each PL, which seems mighty slow and disk-space-hungry. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] alternate regression dbs?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Currently the pg_regress script does dbname=regression and then does everything in terms of $dbname. Would there be any value in providing a --dbname=foo parameter so that different regression sets could use their own db? One virtue at least might be that we would not drop the core regression db all the time - having it around can be useful, I think. I'd be in favor of using three such DBs, one for core, PLs, and contrib. (More than that seems like it would clutter the disk a lot.) But I do use the standard regression DB as a handy testbed for a lot of stuff, and it has bothered me in the past that the contrib installcheck wipes it out. I agree completely, will work on that. Another point in the same general area: it would probably not be hard to support make check as well as make installcheck for the PLs. (The reason it's hard for contrib is that make install doesn't install contrib ... but it does install the PLs.) Is it worth doing it though? The easy implementation would require building a temp install tree for each PL, which seems mighty slow and disk-space-hungry. yes, way too much work if done as a separate run. The only way it would make sense to me would be if we integrated them into the core check run somehow. But I very much doubt it is worth it. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] alternate regression dbs?
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: The easy implementation would require building a temp install tree for each PL, which seems mighty slow and disk-space-hungry. yes, way too much work if done as a separate run. The only way it would make sense to me would be if we integrated them into the core check run somehow. But I very much doubt it is worth it. Yeah. I was seriously thinking of proposing that, until I realized that putting knowledge of the available optional PLs under src/test/regress is probably exactly what we don't want to do, given that there are likely to be more and more of them. We really want that knowledge localized in src/pl. Perhaps src/pl/Makefile could be taught to implement make check (and make installcheck for that matter) at its own level, and run the tests for all the configured PLs using only one installation step. But at the moment it seems more trouble than it's worth. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] alternate regression dbs?
Andrew Dunstan [EMAIL PROTECTED] writes: Try attached ... season to taste. The bulk of it is changes for dblink which has the dbname hardcoded. Joe, any objections here? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] alternate regression dbs?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Try attached ... season to taste. The bulk of it is changes for dblink which has the dbname hardcoded. Joe, any objections here? Haven't been able to keep up with the lists at all for the past few days, but I'll take a look later today. Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
