pgsql: Make postgres.bki use the same literal-string syntax as postgres

2020-10-04 Thread Tom Lane
Make postgres.bki use the same literal-string syntax as postgresql.conf.

The BKI file's string quoting conventions were previously quite weird,
perhaps as a result of repurposing a function built to scan
single-quoted strings to scan double-quoted ones.  Change to use the
same rules as we use in GUC files, allowing some simplifications in
genbki.pl and initdb.c.

While at it, completely remove the backend's scanstr() function, which
was essentially a duplicate of the string dequoting code in guc-file.l.
Instead export that one (under a less generic name than it had) and let
bootscanner.l use it.  Now we can clarify that scansup.c exists only to
support the main lexer. We could alternatively have removed GUC_scanstr,
but this way seems better since the previous arrangement could mislead
a reader into thinking that scanstr() had something to do with the main
lexer's handling of string literals.  Maybe it did once, but if so it
was a long time ago.

This patch does not bump catversion, since the initially-installed
catalog contents don't change.  Note however that successful initdb
after applying this patch will require up-to-date postgres.bki as well
as postgres and initdb executables.

In passing, remove a bunch of very-long-obsolete #include's in
bootparse.y and bootscanner.l.

John Naylor

Discussion: 
https://postgr.es/m/cacpnzctdpd18t0kattmcggo2gdvc4ow86ypiq5enff1vnau...@mail.gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/97b61448262eae5e1b4a631aeac63b11d902a474

Modified Files
--
doc/src/sgml/bki.sgml   | 10 ++--
src/backend/bootstrap/bootparse.y   | 19 
src/backend/bootstrap/bootscanner.l | 29 ++-
src/backend/catalog/genbki.pl   |  6 +--
src/backend/parser/scansup.c| 95 +
src/backend/utils/misc/guc-file.l   | 14 +++---
src/bin/initdb/initdb.c | 34 +++--
src/include/parser/scansup.h|  5 +-
src/include/utils/guc.h |  1 +
9 files changed, 31 insertions(+), 182 deletions(-)



pgsql: Fix handling of redundant options with COPY for "freeze" and "he

2020-10-04 Thread Michael Paquier
Fix handling of redundant options with COPY for "freeze" and "header"

The handling of those options was inconsistent, as the processing used
directly the value assigned to the option to check if it was redundant,
leading to patterns like this one to succeed (note that false is
specified first):
COPY hoge to '/path/to/file/' (header off, header on);

And the opposite would fail correctly (note that true is first here):
COPY hoge to '/path/to/file/' (header on, header off);

While on it, add some tests to check for all redundant patterns with the
options of COPY.  I have gone through the code and did not notice
similar mistakes for other commands.

"header" got it wrong since b63990c, and "freeze" was wrong from the
start as of 8de72b6.  No backpatch is done per the lack of complaints.

Reported-by: Rémi Lapeyre
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/10c5291cc2c6497d5abe04dde7df649d898becc4

Modified Files
--
src/backend/commands/copy.c |  8 +--
src/test/regress/expected/copy2.out | 47 +
src/test/regress/sql/copy2.sql  | 14 +++
3 files changed, 67 insertions(+), 2 deletions(-)



pgsql: Improve stability of identity.sql regression test.

2020-10-04 Thread Tom Lane
Improve stability of identity.sql regression test.

I noticed while trying to run the regression tests under a low
geqo_threshold that one query on information_schema.columns had
unstable (as in, variable from one run to the next) output order.
This is pretty unsurprising given the complexity of the underlying
plan.  Interestingly, of this test's three nigh-identical queries on
information_schema.columns, the other two already had ORDER BY clauses
guaranteeing stable output.  Let's make this one look the same.

Back-patch to v10 where this test was added.  We've not heard field
reports of the test failing, but this experience shows that it can
happen when testing under even slightly unusual conditions.

Branch
--
REL_12_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/5856ed1099d9288a7cee20cff9f95831a96add1c

Modified Files
--
src/test/regress/expected/identity.out | 2 +-
src/test/regress/sql/identity.sql  | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve stability of identity.sql regression test.

2020-10-04 Thread Tom Lane
Improve stability of identity.sql regression test.

I noticed while trying to run the regression tests under a low
geqo_threshold that one query on information_schema.columns had
unstable (as in, variable from one run to the next) output order.
This is pretty unsurprising given the complexity of the underlying
plan.  Interestingly, of this test's three nigh-identical queries on
information_schema.columns, the other two already had ORDER BY clauses
guaranteeing stable output.  Let's make this one look the same.

Back-patch to v10 where this test was added.  We've not heard field
reports of the test failing, but this experience shows that it can
happen when testing under even slightly unusual conditions.

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/e899742081fa24bf52d4a32103ef854a3a85865d

Modified Files
--
src/test/regress/expected/identity.out | 2 +-
src/test/regress/sql/identity.sql  | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve stability of identity.sql regression test.

2020-10-04 Thread Tom Lane
Improve stability of identity.sql regression test.

I noticed while trying to run the regression tests under a low
geqo_threshold that one query on information_schema.columns had
unstable (as in, variable from one run to the next) output order.
This is pretty unsurprising given the complexity of the underlying
plan.  Interestingly, of this test's three nigh-identical queries on
information_schema.columns, the other two already had ORDER BY clauses
guaranteeing stable output.  Let's make this one look the same.

Back-patch to v10 where this test was added.  We've not heard field
reports of the test failing, but this experience shows that it can
happen when testing under even slightly unusual conditions.

Branch
--
REL_10_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/db7c7b88d00b615f203a4984ef0d01c5e2e46a33

Modified Files
--
src/test/regress/expected/identity.out | 2 +-
src/test/regress/sql/identity.sql  | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve stability of identity.sql regression test.

2020-10-04 Thread Tom Lane
Improve stability of identity.sql regression test.

I noticed while trying to run the regression tests under a low
geqo_threshold that one query on information_schema.columns had
unstable (as in, variable from one run to the next) output order.
This is pretty unsurprising given the complexity of the underlying
plan.  Interestingly, of this test's three nigh-identical queries on
information_schema.columns, the other two already had ORDER BY clauses
guaranteeing stable output.  Let's make this one look the same.

Back-patch to v10 where this test was added.  We've not heard field
reports of the test failing, but this experience shows that it can
happen when testing under even slightly unusual conditions.

Branch
--
REL_11_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/0d1f6ae485d8d3d034e3d67dd38cc65ab359f773

Modified Files
--
src/test/regress/expected/identity.out | 2 +-
src/test/regress/sql/identity.sql  | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)



pgsql: Improve stability of identity.sql regression test.

2020-10-04 Thread Tom Lane
Improve stability of identity.sql regression test.

I noticed while trying to run the regression tests under a low
geqo_threshold that one query on information_schema.columns had
unstable (as in, variable from one run to the next) output order.
This is pretty unsurprising given the complexity of the underlying
plan.  Interestingly, of this test's three nigh-identical queries on
information_schema.columns, the other two already had ORDER BY clauses
guaranteeing stable output.  Let's make this one look the same.

Back-patch to v10 where this test was added.  We've not heard field
reports of the test failing, but this experience shows that it can
happen when testing under even slightly unusual conditions.

Branch
--
REL_13_STABLE

Details
---
https://git.postgresql.org/pg/commitdiff/e01e339560ea7d8716924f3b014e902ef646729c

Modified Files
--
src/test/regress/expected/identity.out | 2 +-
src/test/regress/sql/identity.sql  | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)