[HACKERS] Adding CORRESPONDING to Set Operations
Hello, I am new to postgresql code, I would like to start implementing easyish TODO items. I have read most of the development guidelines, faqs, articles by Greg Smith (Hacking Postgres with UDFs, Adding WHEN to triggers). The item I would like to implement is adding CORRESPONDING [BY (col1[,col2,...]])] to INTERSECT and EXCEPT operators. Can anyone comment on how much effort this item needs? regards, kerem kat.
Re: [HACKERS] Double sorting split patch
On 18 September 2011 01:51, Greg Stark st...@mit.edu wrote: I think we provided the qsort implementation for the benefit of platforms that didn't have a decent one and then ended up switching to use it always for some reason I don't recall. It wasn't because we thought we were better at writing qsort implementations than OS vendors. The comment: * We have modified their original by adding a check for already-sorted input, * which seems to be a win per discussions on pgsql-hackers around 2006-03-21. sort of suggests that it *was* at least in part because we thought we could do a better job, but that isn't a significant detail. I wondered in passing if compiler vendors had got around to figuring out a way of solving the inlining function pointer problem that I first read about years ago, so I ran this code, which benchmarks the macro-based qsort above: You might need -fipa-pta or some other option. Or maybe LLVM would have a better chance of pulling this off. Compilers are usually pretty loath to generate specializations for every call site for fear of bloating the code. Compilers do a fairly good job of generating the specialisations appropriately, which leads to the observation that the inline keyword is kind of at the wrong level of granularity, as individual call sites are inlined, not functions. I built this program with a recent build of clang from SVN (left over from my work on Clang a few weeks back, as it happens) on a more powerful machine, and the difference narrowed: C quick-sort time elapsed: 1.89 Inline C quick-sort time elapsed: 1.54 This still seems significant though. In any case I don't see how you're going to inline random database functions. Those are the cases where large amounts of data are being sorted. It's possible we sort small sets of data for internal reasons very frequently but I don't recall it turning up at the top of the profiles posted in recent days. Well, this point was raised in relation to the OP's patch, which does have a couple of simple comparators that look like good candidates for inlining. There are other really simple comparators around like that - one that I'm aware of off-hand is the one used to sort pg_stat_statements entries to find victims. It doesn't have to have major benefits to be worth undertaking - it only has to be worth the effort of its original implementation and ongoing maintenance. Now a JIT that actually inlined random database functions into qsort and optimized the result would be pretty cool. But it doesn't seem like it's going to happen tomorrow... Yeah, that would be extremely cool. I'd guess that the main reason it isn't going to happen tomorrow is not so much technical, but because there would be about a dozen controversies involved in integrating an available, suitable JIT - how does it integrate with the build system, licensing, choice of implementation language, support on less popular platforms, how do package managers handle the dependency, can we trust the developers/steering committee of the JIT (Okay, so I'm really thinking about LLVM here), and so on. That's just off the top of my head. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is there really no interest in SQL Standard?
On fre, 2011-09-16 at 07:38 -0500, Merlin Moncure wrote: So, generally speaking, what kinds of things are going to be brought up at the ISO meeting? Is this an opportunity to get postgres special syntax drafted into the sql standard? Don't expect to take a PostgreSQL-specific feature, say, CREATE RULE or CREATE AGGREGATE, and make it into an ISO standard. The big boys still run the show, and it's unlikely that something gets accepted without buy in from one of the major proprietary vendors. Besides, writing actual standards is difficult and time-consuming work. But what you can accomplish is to mold upcoming features so that they don't clash with PostgreSQL, or better yet benefit PostgreSQL. Also, you can mold future PostgreSQL features in the converse way. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is there really no interest in SQL Standard?
On fre, 2011-09-16 at 08:59 -0500, Dave Page wrote: You're missing my point completely. You say you represent PostgreSQL on the SQL Committee (or German working group, but that's not the point), yet the PostgreSQL hackers didn't know that, and were making other plans less than 2 years ago. For me, a representative would have been reporting back to us after each meeting, and discussing points to raise before each meeting - not working in isolation, without the knowledge of others. Let's not get into legalese. I don't think Susanne's point was the she was the sole and authoritative representative of the project. An alternative way to phrase this might be that she has been the only participant in committee meetings that has had PostgreSQL's concerns on her mind. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels
On fre, 2011-09-16 at 10:57 -0400, Tom Lane wrote: So it looks like it behooves us to cater for oom_score_adj in the future. The simplest, least risky change that I can think of is to copy-and-paste the relevant #ifdef code block in fork_process.c. If we do that, then it would be up to the packager whether to #define LINUX_OOM_ADJ or LINUX_OOM_SCORE_ADJ or both depending on the behavior he wants. There are lots of reasons why that won't work: backports, forward ports, derivatives, custom kernels, distribution upgrades, virtual hosting. ISTM that we could at least query the currently used kernel version. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is there really no interest in SQL Standard?
On Sunday, September 18, 2011, Peter Eisentraut pete...@gmx.net wrote: On fre, 2011-09-16 at 08:59 -0500, Dave Page wrote: You're missing my point completely. You say you represent PostgreSQL on the SQL Committee (or German working group, but that's not the point), yet the PostgreSQL hackers didn't know that, and were making other plans less than 2 years ago. For me, a representative would have been reporting back to us after each meeting, and discussing points to raise before each meeting - not working in isolation, without the knowledge of others. Let's not get into legalese. I don't think Susanne's point was the she was the sole and authoritative representative of the project. An alternative way to phrase this might be that she has been the only participant in committee meetings that has had PostgreSQL's concerns on her mind. That is much more reasonable, though unfortunately not what was said. Regardless, I stand by my main point that such a representative should be communicating with the project regularly. Having a rep who works outside the project is of no use at all. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: [HACKERS] Is there really no interest in SQL Standard?
Susanne Ebrecht wrote: Since 4 years I am PostgreSQL representative in SQL Standard committee. I wasn't aware of that. Thanks for taking the time to look out for community interests. The next ISO meeting will be soon - and of course there are lots of drafts that needs decisions. As others have stated, I think it would be appropriate to discuss the issues under consideration on this list. A non-public list could make sense if it would allow you to share draft language in a way which wouldn't be possible here; those who wish to support your efforts in that regard could subscribe. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is there really no interest in SQL Standard?
On sön, 2011-09-18 at 09:45 -0500, Dave Page wrote: That is much more reasonable, though unfortunately not what was said. Regardless, I stand by my main point that such a representative should be communicating with the project regularly. Having a rep who works outside the project is of no use at all. Well, the point of this thread is, how can she communicate? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 2011-09 CF underway
The 2nd CommitFest for 9.2 is in progress. It is scheduled to run from September 15th (three days ago) until October 15th (just under four weeks from now). No new patches should be added to it (although, obviously, new versions of patches already in the CF are expected). Although this is just three days in, I have good news and bad news. Many thanks to those who have gotten a jump on reviews for the CF. Due to their efforts, of the 53 patches submitted, 16 patches (30%) have been disposed. That's a great place to be three days into a CF. On the other hand, of the 34 patches currently in need of review, only 8 (less than 24%) have reviewers assigned. We desperately need more people to volunteer to review patches. If you are not yet participating in the CF, please read this page and join the effort: http://wiki.postgresql.org/wiki/RRReviewers We need your help to keep the development process productive, so that we can continue to add features and improve performance while maintaining the rock-solid reliability we all enjoy. -Kevin P.S. I apologize for not being on top of the opening of the CF as I intended. Many thanks to Robert Haas for getting things set up on the 14th. I'll be doing another round of checking on the status of the patches today, and will then join in the patch review myself. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Range Types - typo + NULL string constructor
On Tue, September 13, 2011 10:41, Jeff Davis wrote: Another updated patch is attached. Hi, Below are 2 changes. The first change is an elog saying 'lower' instead of 'upper'. The second change is less straightforward, but I think it should be changed too: Rangetypes as it stands uses NULL to indicate INF or -INF: select int4range(2, NULL); int4range [ 2, INF ) (1 row) but refuses to accept it in the string-form: select '[ 2 , NULL )'::int4range; ERROR: NULL range boundaries are not supported LINE 1: select '[ 2 , NULL )'::int4range; ^ Second part below changes that to accept NULL for INF and -INF in the string-form construction. (not complete: it still is case-sensitive). Thanks, Erik Rijkers --- src/backend/utils/adt/rangetypes.c.orig 2011-09-18 12:35:29.0 +0200 +++ src/backend/utils/adt/rangetypes.c 2011-09-18 16:03:34.0 +0200 @@ -387,7 +387,7 @@ if (empty) elog(ERROR, range is empty); if (upper.infinite) - elog(ERROR, range lower bound is infinite); + elog(ERROR, range upper bound is infinite); PG_RETURN_DATUM(upper.val); } @@ -1579,9 +1579,9 @@ fl = RANGE_EMPTY; if (!lb_quoted strncmp(lb, NULL, ilen) == 0) - elog(ERROR, NULL range boundaries are not supported); + fl |= RANGE_LB_INF; if (!ub_quoted strncmp(ub, NULL, ilen) == 0) - elog(ERROR, NULL range boundaries are not supported); + fl |= RANGE_UB_INF; if (!lb_quoted strncmp(lb, -INF, ilen) == 0) fl |= RANGE_LB_INF; if (!ub_quoted strncmp(ub, INF, ilen) == 0) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] /proc/self/oom_adj is deprecated in newer Linux kernels
Peter Eisentraut pete...@gmx.net writes: On fre, 2011-09-16 at 10:57 -0400, Tom Lane wrote: So it looks like it behooves us to cater for oom_score_adj in the future. The simplest, least risky change that I can think of is to copy-and-paste the relevant #ifdef code block in fork_process.c. If we do that, then it would be up to the packager whether to #define LINUX_OOM_ADJ or LINUX_OOM_SCORE_ADJ or both depending on the behavior he wants. There are lots of reasons why that won't work: backports, forward ports, derivatives, custom kernels, distribution upgrades, virtual hosting. [ shrug... ] These are all hypothetical reasons. A packager who foresaw needing that could just turn on both write attempts, or for that matter patch the code to do whatever else he saw fit. In practice, we've not had requests for anything significantly smarter than what is there. But having said that, it wouldn't be very hard to arrange things so that if you did have both symbols defined, the code would only attempt to write oom_adj if it had failed to write oom_score_adj; which is about as close as you're likely to get to a kernel version test for this. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is there really no interest in SQL Standard?
Peter Eisentraut pete...@gmx.net writes: On sön, 2011-09-18 at 09:45 -0500, Dave Page wrote: That is much more reasonable, though unfortunately not what was said. Regardless, I stand by my main point that such a representative should be communicating with the project regularly. Having a rep who works outside the project is of no use at all. Well, the point of this thread is, how can she communicate? +1 for a closed mailing list. It's a bit annoying to have to do such a thing, but it's not like we haven't got other closed lists for appropriate purposes. I guess the real question is, exactly what will be the requirements for joining? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Grouping Sets
Hi, I tried to apply the Grouping Sets Patch to 8.4, but received several Hunks failed messages, does anyone know if the failing hunks can be applied manually? Or what version they were applied to specifically? -- Regards David
Re: [HACKERS] [WIP] Caching constant stable expressions per execution
On Mon, Sep 12, 2011 at 00:22, Tom Lane t...@sss.pgh.pa.us wrote: The other thing that is going to be an issue is that I'm fairly sure this breaks plpgsql's handling of simple expressions. The quick and dirty solution to this would be for plpgsql to pass some kind of planner flag that disables insertion of CacheExpr nodes, or alternatively have it not believe that CacheExpr nodes are safe to have in simple expressions. But that gives up all the advantage of the concept for this use-case, which seems a bit disappointing. Maybe we can think of a better answer. I got around to this and I think there's a better way. PL/pgSQL simple expressions are queries that return a single row, a single column, don't reference any tables, have no WHERE clauses etc. All expressions in such queries would be evaluated only once anyway, so don't benefit from cache -- and indeed could potentially be hurt by the added overheads. It seems that we could pre-empt this in the planner by recognizing potentially-simple queries right from the start and forbidding CacheExpr. Maybe add a new boolean to PlannerInfo? However, I got stuck because set-returning functions aren't immediately obvious -- I'd have to walk the whole expression tree to find out. A query like SELECT now(), generate_series(1,10) isn't a simple expression and could still benefit from cache for the now() call. Or we could just let it slip and not cache anything if there's no FROM/WHERE clause. Thoughts? Regards, Marti -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [REVIEW] Generate column names for subquery expressions
On Wed, Sep 14, 2011 at 05:26, Kyotaro HORIGUCHI
horiguchi.kyot...@oss.ntt.co.jp wrote:
This is a review for the patch `Generate column names for
subquery expressions'
(https://commitfest.postgresql.org/action/patch_view?id=632)
Thanks for the review. :)
PS: When you send a review, you should add the author's email to the
To: line to make sure they see it. I noticed your email only today
because it was in a new thread and not addressed to me directly.
I think this patch needs no documentation, but it is needed to
edit the changed behaviors quoted in document. Maybe only one
change as far as I have seen.
http://www.postgresql.org/docs/9.0/static/sql-expressions.html
SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
?column?
-
{2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31}
Good catch, a new patch is attached. Apparently the results of this
query have also changed in recent versions, but I didn't touch that.
Regards,
Marti
From 0defe411697f84d26e6f23970d90c70cd057c298 Mon Sep 17 00:00:00 2001
From: Marti Raudsepp ma...@juffo.org
Date: Tue, 6 Sep 2011 21:17:54 +0300
Subject: [PATCH] Generate column names for subquery expressions instead of
?column?
Previously these select expressions didn't have column names:
select (SELECT colname FROM tab) = colname
select (SELECT 1 AS foo) = foo
select exists(SELECT 1) = exists
select array(SELECT 1) = array
This change makes the subquery column name take precedence over weak
column names. Previously these two would return int4 and case, now
they return foo:
select (select 1 foo)::int
select case when true then 1 else (select 1 as foo) end
---
doc/src/sgml/syntax.sgml |2 +-
src/backend/parser/parse_target.c| 33 ++
src/test/regress/expected/aggregates.out |6 ++--
src/test/regress/expected/subselect.out | 12 +-
src/test/regress/expected/with.out |4 +-
5 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index 9119b60..ab81f78 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -2109,7 +2109,7 @@ SELECT ARRAY[]::integer[];
bracketed) subquery. For example:
programlisting
SELECT ARRAY(SELECT oid FROM pg_proc WHERE proname LIKE 'bytea%');
- ?column?
+array
-
{2011,1954,1948,1952,1951,1244,1950,2005,1949,1953,2006,31}
(1 row)
diff --git a/src/backend/parser/parse_target.c b/src/backend/parser/parse_target.c
index 9d4e580..685233c 100644
--- a/src/backend/parser/parse_target.c
+++ b/src/backend/parser/parse_target.c
@@ -1585,6 +1585,39 @@ FigureColnameInternal(Node *node, char **name)
return FigureColnameInternal(ind-arg, name);
}
break;
+ case T_SubLink:
+ switch (((SubLink *) node)-subLinkType)
+ {
+case EXISTS_SUBLINK:
+ *name = exists;
+ return 2;
+case ARRAY_SUBLINK:
+ *name = array;
+ return 2;
+case EXPR_SUBLINK:
+ /* Get column name from the subquery's target list */
+ {
+ SubLink *sublink = (SubLink *) node;
+ Query *query = (Query *) sublink-subselect;
+ /* EXPR_SUBLINK always has a single target */
+ TargetEntry *te = (TargetEntry *) linitial(query-targetList);
+
+ /* Subqueries have already been transformed */
+ if(te-resname)
+ {
+ *name = te-resname;
+ return 2;
+ }
+ }
+ break;
+/* As with other operator-like nodes, these don't really have names */
+case ALL_SUBLINK:
+case ANY_SUBLINK:
+case ROWCOMPARE_SUBLINK:
+case CTE_SUBLINK:
+ break;
+ }
+ break;
case T_FuncCall:
*name = strVal(llast(((FuncCall *) node)-funcname));
return 2;
diff --git a/src/test/regress/expected/aggregates.out b/src/test/regress/expected/aggregates.out
index 4861006..69926f7 100644
--- a/src/test/regress/expected/aggregates.out
+++ b/src/test/regress/expected/aggregates.out
@@ -300,9 +300,9 @@ LINE 4:where sum(distinct a.four + b.four) = b.four)...
select
(select max((select i.unique2 from tenk1 i where i.unique1 = o.unique1)))
from tenk1 o;
- ?column?
---
-
+ max
+--
+
(1 row)
--
diff --git a/src/test/regress/expected/subselect.out b/src/test/regress/expected/subselect.out
index e638f0a..4ea8211 100644
--- a/src/test/regress/expected/subselect.out
+++ b/src/test/regress/expected/subselect.out
@@ -490,20 +490,20 @@ select view_a from view_a;
(1 row)
select (select view_a) from view_a;
- ?column?
---
+ view_a
+
(42)
(1 row)
select (select (select view_a)) from view_a;
- ?column?
---
+ view_a
+
(42)
(1 row)
select (select (a.*)::text) from view_a a;
- ?column?
---
+ a
+--
(42)
Re: [HACKERS] unite recovery.conf and postgresql.conf
On Fri, Sep 16, 2011 at 3:22 PM, Joshua Berkus j...@agliodbs.com wrote: No. pg_settings already has a couple dozen developer parameters which nobody not on this mailing list understands. Adding the recovery parameters to it wouldn't confuse anyone further, and would have the advantage of making the recovery parameters available by monitoring query on a hot standby. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade automatic testing
On mån, 2011-09-05 at 23:42 +0300, Peter Eisentraut wrote:
On lör, 2011-09-03 at 19:58 -0400, Tom Lane wrote:
Anyway, after giving up on that I went back to plan A, namely install
regress.so and friends into $libdir. That turns out to be really quite
straightforward, though I had to hack pg_regress.c a bit to get its idea
of $libdir to match up exactly with the way the backend sees it.
(The only reason this matters is that there's one error report in the
regression tests where the full expansion of $libdir is reported.
Maybe we should just drop that one test case instead of maintaining
the infrastructure for replacing @libdir@ in pg_regress.c.)
Attached is a draft patch for HEAD. It passes make check and make
installcheck on Unix, but I've not touched the MSVC scripts.
Comments?
I'll try to integrate this with my pg_upgrade test runner to see if it
gets the job done.
I found a simpler way to get this working. Just hack up the catalogs
for the new path directly. So I can now run this test suite against
older versions as well, like this:
contrib/pg_upgrade$ make installcheck oldsrc=somewhere oldbindir=elsewhere
The status is:
master - master works.
9.1 - master works.
9.0 - master kind of works. The upgrade succeeds, but the dump has
differences because the languages are now dumped as extension commands.
It's easy to inspect manually, but won't work for any kind of automated
test runs.
8.4 - master upgrade fails like this:
Restoring user relation files
Mismatch of relation names in database regression: old name
pg_toast.pg_toast_27437, new name pg_toast.pg_toast_27309
Failure, exiting
This has been 100% reproducible for me.
8.3 - master upgrade doesn't work at all, because the regression test
database contains columns of type name and pg_upgrade won't upgrade
those from this version.
diff --git a/contrib/pg_upgrade/.gitignore b/contrib/pg_upgrade/.gitignore
index 03ec737..79c8cdb 100644
--- a/contrib/pg_upgrade/.gitignore
+++ b/contrib/pg_upgrade/.gitignore
@@ -1 +1,5 @@
/pg_upgrade
+# Generated by test suite
+delete_old_cluster.sh
+/log/
+/tmp_check/
diff --git a/contrib/pg_upgrade/Makefile b/contrib/pg_upgrade/Makefile
index 8f3fd7c..7f97b3d 100644
--- a/contrib/pg_upgrade/Makefile
+++ b/contrib/pg_upgrade/Makefile
@@ -21,3 +21,11 @@ top_builddir = ../..
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
endif
+
+check: test.sh
+ MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) $(SHELL) $ --install
+
+installcheck: test.sh
+ MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) $(SHELL) $
+
+EXTRA_CLEAN = delete_old_cluster.sh log/ tmp_check/
diff --git a/contrib/pg_upgrade/test.sh b/contrib/pg_upgrade/test.sh
new file mode 100644
index 000..9aebee9
--- /dev/null
+++ b/contrib/pg_upgrade/test.sh
@@ -0,0 +1,123 @@
+#!/bin/sh
+
+# contrib/pg_upgrade/test.sh
+#
+# Test driver for pg_upgrade. Initializes a new database cluster,
+# runs the regression tests (to put in some data), runs pg_dumpall,
+# runs pg_upgrade, runs pg_dumpall again, compares the dumps.
+#
+# Portions Copyright (c) 1996-2011, PostgreSQL Global Development Group
+# Portions Copyright (c) 1994, Regents of the University of California
+
+set -e
+
+: ${MAKE=make}
+: ${PGPORT=50432}
+export PGPORT
+
+temp_root=$PWD/tmp_check
+
+if [ $1 = '--install' ]; then
+ temp_install=$temp_root/install
+ bindir=$temp_install/$bindir
+ libdir=$temp_install/$libdir
+
+ $MAKE -s -C ../.. install DESTDIR=$temp_install
+ $MAKE -s -C ../pg_upgrade_support install DESTDIR=$temp_install
+ $MAKE -s -C . install DESTDIR=$temp_install
+
+ # platform-specific magic to find the shared libraries; see pg_regress.c
+ LD_LIBRARY_PATH=$libdir:$LD_LIBRARY_PATH
+ export LD_LIBRARY_PATH
+ DYLD_LIBRARY_PATH=$libdir:$DYLD_LIBRARY_PATH
+ export DYLD_LIBRARY_PATH
+ LIBPATH=$libdir:$LIBPATH
+ export LIBPATH
+ PATH=$libdir:$PATH
+
+ # We need to make it use psql from our temporary installation,
+ # because otherwise the installcheck run below would try to
+ # use psql from the proper installation directory, which might
+ # be outdated or missing.
+ EXTRA_REGRESS_OPTS=--psqldir=$bindir
+ export EXTRA_REGRESS_OPTS
+fi
+
+: ${oldbindir=$bindir}
+
+: ${oldsrc=../..}
+oldsrc=`cd $oldsrc pwd`
+newsrc=`cd ../.. pwd`
+
+PATH=$bindir:$PATH
+export PATH
+
+PGDATA=$temp_root/data
+export PGDATA
+rm -rf $PGDATA $PGDATA.old
+
+logdir=$PWD/log
+rm -rf $logdir
+mkdir $logdir
+
+set -x
+
+$oldbindir/initdb
+$oldbindir/pg_ctl start -l $logdir/postmaster1.log -w
+if $MAKE -C $oldsrc installcheck; then
+ pg_dumpall $temp_root/dump1.sql || pg_dumpall1_status=$?
+ if [ $newsrc != $oldsrc ]; then
+ oldpgversion=`psql -A -t -d regression -c SHOW server_version_num`
+ fix_sql=
+ case $oldpgversion in
+ 804??)
+fix_sql=UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%'; DROP FUNCTION public.myfunc(integer);
+;;
+ 900??)
+fix_sql=SET
