pgsql: test_ddl_deparse: Don't use pg_class as source for a matview

2018-03-15 Thread Alvaro Herrera
test_ddl_deparse: Don't use pg_class as source for a matview Doing so causes a pg_upgrade of a database containing these objects to fail whenever pg_class changes. And it's pointless anyway: we have more interesting tables anyhow. Discussion: https://postgr.es/m/CAD5tBc+s8pW9WvH2+_z=b4x95fd4quz

pgsql: test_ddl_deparse: Don't use pg_class as source for a matview

2018-03-15 Thread Alvaro Herrera
test_ddl_deparse: Don't use pg_class as source for a matview Doing so causes a pg_upgrade of a database containing these objects to fail whenever pg_class changes. And it's pointless anyway: we have more interesting tables anyhow. Discussion: https://postgr.es/m/CAD5tBc+s8pW9WvH2+_z=b4x95fd4quz

pgsql: test_ddl_deparse: Don't use pg_class as source for a matview

2018-03-15 Thread Alvaro Herrera
test_ddl_deparse: Don't use pg_class as source for a matview Doing so causes a pg_upgrade of a database containing these objects to fail whenever pg_class changes. And it's pointless anyway: we have more interesting tables anyhow. Discussion: https://postgr.es/m/CAD5tBc+s8pW9WvH2+_z=b4x95fd4quz

pgsql: test_ddl_deparse: Don't use pg_class as source for a matview

2018-03-15 Thread Alvaro Herrera
test_ddl_deparse: Don't use pg_class as source for a matview Doing so causes a pg_upgrade of a database containing these objects to fail whenever pg_class changes. And it's pointless anyway: we have more interesting tables anyhow. Discussion: https://postgr.es/m/CAD5tBc+s8pW9WvH2+_z=b4x95fd4quz

Re: pgsql: Remove pg_class.relhaspkey

2018-03-15 Thread Alvaro Herrera
Andrew Dunstan wrote: > As I mentioned upthread, it's not supposed to be, but was being due to > a typo that I have fixed. You should see this error cleared on the > dashboard in a few minutes. > > However, in general the module tries to do a maximal test. That > includes almost all the contrib d

pgsql: restrict -> pg_restrict

2018-03-15 Thread Alvaro Herrera
restrict -> pg_restrict So that it works on MSVC, too. Author: Michaël Paquier Discussion: https://postgr.es/m/29889.1520968...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8d1b805fcc57be47d3269a13eb01d993fe768295 Modified Files -- src

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Alvaro Herrera
Michael Paquier wrote: > Attached is a patch which fixes the compilation failure on Windows for > me. That should put the buildfarm back to green. Pushed, thanks -- let's see how that goes. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remo

Re: pgsql: Remove pg_class.relhaspkey

2018-03-15 Thread Tom Lane
Alvaro Herrera writes: > Well, maybe we should dictate policy that it must be possible to > pg_upgrade this database too; then we'll just have to work so that it > always works. I have fixed the current problem and I'm open to the idea > of keeping it working. Name of the matview now seems a bit

pgsql: Pass additional arguments to a couple of grouping-related functi

2018-03-15 Thread Robert Haas
Pass additional arguments to a couple of grouping-related functions. get_number_of_groups() and make_partial_grouping_target() currently fish information directly out of the PlannerInfo; in the former case, the target list, and in the latter case, the HAVING qual. This works fine if there's only

pgsql: Fix more format truncation issues

2018-03-15 Thread Peter Eisentraut
Fix more format truncation issues Fix the warnings created by the compiler warning options -Wformat-overflow=2 -Wformat-truncation=2, supported since GCC 7. This is a more aggressive variant of the fixes in 6275f5d28a1577563f53f2171689d4f890a46881, which GCC 7 warned about by default. The issues

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Tom Lane
Alvaro Herrera writes: > Michael Paquier wrote: >> Attached is a patch which fixes the compilation failure on Windows for >> me. That should put the buildfarm back to green. > Pushed, thanks -- let's see how that goes. build now works, ecpg tests fail. regards, tom lane

pgsql: Clean up duplicate role and schema names in regression tests.

2018-03-15 Thread Tom Lane
Clean up duplicate role and schema names in regression tests. Since these names are global, using the same ones in different regression tests creates a hazard of test failures if any two such scripts run concurrently. Let's establish a policy of not doing that. In the cases where a conflict exis

pgsql: Clean up duplicate role and schema names in regression tests.

2018-03-15 Thread Tom Lane
Clean up duplicate role and schema names in regression tests. Since these names are global, using the same ones in different regression tests creates a hazard of test failures if any two such scripts run concurrently. Let's establish a policy of not doing that. In the cases where a conflict exis

pgsql: test_ddl_deparse: rename matview

2018-03-15 Thread Alvaro Herrera
test_ddl_deparse: rename matview Should have done this in e69f5e0efca ... Per note from Tom Lane. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/492ba06942347dc20721db77fe00460013d9dc70 Modified Files -- src/test/modules/test_ddl_deparse/expecte

pgsql: test_ddl_deparse: rename matview

2018-03-15 Thread Alvaro Herrera
test_ddl_deparse: rename matview Should have done this in e69f5e0efca ... Per note from Tom Lane. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a446a1c70f65c6c68598c2160b530606fa1b5c38 Modified Files -- src/test/modules/test_ddl_deparse/expected/matvi

pgsql: test_ddl_deparse: rename matview

2018-03-15 Thread Alvaro Herrera
test_ddl_deparse: rename matview Should have done this in e69f5e0efca ... Per note from Tom Lane. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/eb1c481ac3975574c1709042efe2c6c32a937a23 Modified Files -- src/test/modules/test_ddl_deparse/expecte

pgsql: test_ddl_deparse: rename matview

2018-03-15 Thread Alvaro Herrera
test_ddl_deparse: rename matview Should have done this in e69f5e0efca ... Per note from Tom Lane. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/12bcecae10f7986407fedeb3dd795556027a9d96 Modified Files -- src/test/modules/test_ddl_deparse/expecte

pgsql: Split create_grouping_paths into degenerate and non-degenerate c

2018-03-15 Thread Robert Haas
Split create_grouping_paths into degenerate and non-degenerate cases. There's no functional change here, or at least I hope there isn't, just code rearrangement. The rearrangement is motivated by partition-wise aggregate, which doesn't need to consider the degenerate case but wants to reuse the l

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera writes: > > Michael Paquier wrote: > >> Attached is a patch which fixes the compilation failure on Windows for > >> me. That should put the buildfarm back to green. > > > Pushed, thanks -- let's see how that goes. > > build now works, ecpg tests fail. I stared

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Alvaro Herrera
ah, but bowerbird is OK on ecpg, this is only failing on thrips, whelk, woodlouse. It sounds related to 32 vs. 64 bits ... -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql: Clean up duplicate table and function names in regression tests.

2018-03-15 Thread Tom Lane
Clean up duplicate table and function names in regression tests. Many of the objects we create during the regression tests are put in the public schema, so that using the same names in different regression tests creates a hazard of test failures if any two such scripts run concurrently. This patch

pgsql: Clean up duplicate table and function names in regression tests.

2018-03-15 Thread Tom Lane
Clean up duplicate table and function names in regression tests. Many of the objects we create during the regression tests are put in the public schema, so that using the same names in different regression tests creates a hazard of test failures if any two such scripts run concurrently. This patch

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> build now works, ecpg tests fail. > I stared at the code for a while, didn't notice anything amiss. I'm > mystified. Peter? I'm wondering if the Windows environment is somehow supplying a "strtoint" that isn't actually ABI-compatible with ours. A di

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Tom Lane
Oh ... duh. We've been assuming that the strtoint change broke it, but that's wrong. The test case that is failing is new as of yesterday, and the correct answer is that it's never worked on Windows. See https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=3b7ab4380440d7b14ee390fa

Re: pgsql: Add tests for reinit.c

2018-03-15 Thread Tom Lane
Peter Eisentraut writes: > Add tests for reinit.c BTW, buildfarm member jacana hasn't succeeded at this test once. The failures look like ok 1 - init fork in base exists ok 2 - main fork in base exists error running SQL: 'psql::1: ERROR: directory "/home/pgrunner/bf/root/HEAD/pgsql.build/src/t

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Michael Paquier
On Thu, Mar 15, 2018 at 06:57:27PM -0400, Tom Lane wrote: > I think what's wrong is that src/tools/msvc/ecpg_regression.proj > needs to be taught that tests under ecpg/test/compat-oracle need > to be run with "-C ORACLE". Neither that directory nor that > switch existed before yesterday. There's

pgsql: Fix msvc/ecpg_regression.proj for recent ECPG test additions.

2018-03-15 Thread Tom Lane
Fix msvc/ecpg_regression.proj for recent ECPG test additions. Commit 3b7ab4380 added some tests that require ecpg to be given the new "-C ORACLE" switch. Teach the MSVC build infrastructure about that. Michael Paquier Discussion: https://postgr.es/m/8299.1521154...@sss.pgh.pa.us Branch --

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Tom Lane
Michael Paquier writes: > On Thu, Mar 15, 2018 at 06:57:27PM -0400, Tom Lane wrote: >> I think what's wrong is that src/tools/msvc/ecpg_regression.proj >> needs to be taught that tests under ecpg/test/compat-oracle need >> to be run with "-C ORACLE". Neither that directory nor that >> switch exis

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Tom Lane
Alvaro Herrera writes: > ah, but bowerbird is OK on ecpg, this is only failing on thrips, whelk, > woodlouse. It sounds related to 32 vs. 64 bits ... BTW, the reason why bowerbird was green had nothing to do with 32 or 64 bits, but rather that it isn't running the ecpg tests: 'i

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Michael Paquier
On Thu, Mar 15, 2018 at 10:37:06PM -0400, Tom Lane wrote: > Seems sane AFAICT, so pushed. Thanks! Thanks, Tom. -- Michael signature.asc Description: PGP signature

Re: pgsql: Add tests for reinit.c

2018-03-15 Thread Tom Lane
I wrote: > Peter Eisentraut writes: >> Add tests for reinit.c > BTW, buildfarm member jacana hasn't succeeded at this test once. > The failures look like > ok 1 - init fork in base exists > ok 2 - main fork in base exists > error running SQL: 'psql::1: ERROR: directory > "/home/pgrunner/bf/roo

Re: pgsql: Move strtoint() to common

2018-03-15 Thread Andrew Dunstan
On Fri, Mar 16, 2018 at 1:12 PM, Tom Lane wrote: > Alvaro Herrera writes: > > ah, but bowerbird is OK on ecpg, this is only failing on thrips, whelk, > > woodlouse. It sounds related to 32 vs. 64 bits ... > > BTW, the reason why bowerbird was green had nothing to do with 32 > or 64 bits, but ra