delta/postgresql.git/src/interfaces/ecpg/test/expected, branch master git.postgresql.org: git/postgresql.git ecpg: Fix handling of strings in ORACLE compat code with SQLDA 2023-04-18T02:20:41+00:00 Michael Paquier michael@paquier.xyz 2023-04-18T02:20:41+00:00 f18029084784ec71a2e825cfcfd81b06d597ab93 When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where it would incorrectly store the null terminator byte to str[-1] when varcharsize is 0, which is something that can happen when using SQLDA. This would eat 1 byte from the previous field stored, corrupting the results generated. All the callers of ecpg_get_data() estimate and allocate enough storage for the data received, and the fix of this commit relies on this assumption. Note that this maps to the case where no padding or truncation is required. This issue has been introduced by 3b7ab43 with the Oracle compatibility option, so backpatch down to v11. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20230410.173500.440060475837236886.horikyota.ntt@gmail.com Backpatch-through: 11 
When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where
it would incorrectly store the null terminator byte to str[-1] when
varcharsize is 0, which is something that can happen when using SQLDA.
This would eat 1 byte from the previous field stored, corrupting the
results generated.

All the callers of ecpg_get_data() estimate and allocate enough storage
for the data received, and the fix of this commit relies on this
assumption.  Note that this maps to the case where no padding or
truncation is required.

This issue has been introduced by 3b7ab43 with the Oracle compatibility
option, so backpatch down to v11.

Author: Kyotaro Horiguchi
Discussion: https://postgr.es/m/20230410.173500.440060475837236886.horikyota.ntt@gmail.com
Backpatch-through: 11
SQL/JSON: support the IS JSON predicate 2023-03-31T20:34:04+00:00 Alvaro Herrera alvherre@alvh.no-ip.org 2023-03-31T20:34:04+00:00 6ee30209a6f161d0a267a33f090c70c579c87c00 This patch introduces the SQL standard IS JSON predicate. It operates on text and bytea values representing JSON, as well as on the json and jsonb types. Each test has IS and IS NOT variants and supports a WITH UNIQUE KEYS flag. The tests are: IS JSON [VALUE] IS JSON ARRAY IS JSON OBJECT IS JSON SCALAR These should be self-explanatory. The WITH UNIQUE KEYS flag makes these return false when duplicate keys exist in any object within the value, not necessarily directly contained in the outermost object. Author: Nikita Glukhov <n.gluhov@postgrespro.ru> Author: Teodor Sigaev <teodor@sigaev.ru> Author: Oleg Bartunov <obartunov@gmail.com> Author: Alexander Korotkov <aekorotkov@gmail.com> Author: Amit Langote <amitlangote09@gmail.com> Author: Andrew Dunstan <andrew@dunslane.net> Reviewers have included (in no particular order) Andres Freund, Alexander Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu, Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby. Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org 
This patch introduces the SQL standard IS JSON predicate. It operates
on text and bytea values representing JSON, as well as on the json and
jsonb types. Each test has IS and IS NOT variants and supports a WITH
UNIQUE KEYS flag. The tests are:

IS JSON [VALUE]
IS JSON ARRAY
IS JSON OBJECT
IS JSON SCALAR

These should be self-explanatory.

The WITH UNIQUE KEYS flag makes these return false when duplicate keys
exist in any object within the value, not necessarily directly contained
in the outermost object.

Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Andrew Dunstan <andrew@dunslane.net>

Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.

Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
SQL/JSON: add standard JSON constructor functions 2023-03-29T10:11:36+00:00 Alvaro Herrera alvherre@alvh.no-ip.org 2023-03-29T10:11:36+00:00 7081ac46ace8c459966174400b53418683c9fe5c This commit introduces the SQL/JSON standard-conforming constructors for JSON types: JSON_ARRAY() JSON_ARRAYAGG() JSON_OBJECT() JSON_OBJECTAGG() Most of the functionality was already present in PostgreSQL-specific functions, but these include some new functionality such as the ability to skip or include NULL values, and to allow duplicate keys or throw error when they are found, as well as the standard specified syntax to specify output type and format. Author: Nikita Glukhov <n.gluhov@postgrespro.ru> Author: Teodor Sigaev <teodor@sigaev.ru> Author: Oleg Bartunov <obartunov@gmail.com> Author: Alexander Korotkov <aekorotkov@gmail.com> Author: Amit Langote <amitlangote09@gmail.com> Reviewers have included (in no particular order) Andres Freund, Alexander Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu, Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby. Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org 
This commit introduces the SQL/JSON standard-conforming constructors for
JSON types:

JSON_ARRAY()
JSON_ARRAYAGG()
JSON_OBJECT()
JSON_OBJECTAGG()

Most of the functionality was already present in PostgreSQL-specific
functions, but these include some new functionality such as the ability
to skip or include NULL values, and to allow duplicate keys or throw
error when they are found, as well as the standard specified syntax to
specify output type and format.

Author: Nikita Glukhov <n.gluhov@postgrespro.ru>
Author: Teodor Sigaev <teodor@sigaev.ru>
Author: Oleg Bartunov <obartunov@gmail.com>
Author: Alexander Korotkov <aekorotkov@gmail.com>
Author: Amit Langote <amitlangote09@gmail.com>

Reviewers have included (in no particular order) Andres Freund, Alexander
Korotkov, Pavel Stehule, Andrew Alsup, Erik Rijkers, Zihong Yu,
Himanshu Upadhyaya, Daniel Gustafsson, Justin Pryzby.

Discussion: https://postgr.es/m/CAF4Au4w2x-5LTnN_bxky-mq4=WOqsGsxSpENCzHRAzSnEd8+WQ@mail.gmail.com
Discussion: https://postgr.es/m/cd0bb935-0158-78a7-08b5-904886deac4b@postgrespro.ru
Discussion: https://postgr.es/m/20220616233130.rparivafipt6doj3@alap3.anarazel.de
Discussion: https://postgr.es/m/abd9b83b-aa66-f230-3d6d-734817f0995d%40postgresql.org
Use ICU by default at initdb time. 2023-03-09T18:52:41+00:00 Jeff Davis jdavis@postgresql.org 2023-03-09T18:52:41+00:00 27b62377b47f9e7bf58613608bc718c86ea91e91 If the ICU locale is not specified, initialize the default collator and retrieve the locale name from that. Discussion: https://postgr.es/m/510d284759f6e943ce15096167760b2edcb2e700.camel@j-davis.com Reviewed-by: Peter Eisentraut 
If the ICU locale is not specified, initialize the default collator
and retrieve the locale name from that.

Discussion: https://postgr.es/m/510d284759f6e943ce15096167760b2edcb2e700.camel@j-davis.com
Reviewed-by: Peter Eisentraut
Harmonize parameter names in ecpg code. 2022-09-22T19:53:20+00:00 Peter Geoghegan pg@bowt.ie 2022-09-22T19:53:20+00:00 3535ebce5dc542b90f14d6e81cce80fe7226bda5 Make ecpg function declarations consistently use named parameters. Also make sure that the declarations use names that match corresponding names from function definitions. Like other recent commits that cleaned up function parameter names, this commit was written with help from clang-tidy. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com 
Make ecpg function declarations consistently use named parameters.  Also
make sure that the declarations use names that match corresponding names
from function definitions.

Like other recent commits that cleaned up function parameter names, this
commit was written with help from clang-tidy.

Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-By: David Rowley <dgrowleyml@gmail.com>
Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com
Fix possible omission of variable storage markers in ECPG. 2022-09-09T19:34:04+00:00 Tom Lane tgl@sss.pgh.pa.us 2022-09-09T19:34:04+00:00 b7050e2584803a6abe71fb0b94a63b63e59cff9c The ECPG preprocessor converted code such as static varchar str1[10], str2[20], str3[30]; into static struct varchar_1 { int len; char arr[ 10 ]; } str1 ; struct varchar_2 { int len; char arr[ 20 ]; } str2 ; struct varchar_3 { int len; char arr[ 30 ]; } str3 ; thus losing the storage attribute for the later variables. Repeat the declaration for each such variable. (Note that this occurred only for variables declared "varchar" or "bytea", which may help explain how it escaped detection for so long.) Andrey Sokolov Discussion: https://postgr.es/m/942241662288242@mail.yandex.ru 
The ECPG preprocessor converted code such as

static varchar str1[10], str2[20], str3[30];

into

static  struct varchar_1  { int len; char arr[ 10 ]; }  str1 ;
        struct varchar_2  { int len; char arr[ 20 ]; }  str2 ;
        struct varchar_3  { int len; char arr[ 30 ]; }  str3 ;

thus losing the storage attribute for the later variables.
Repeat the declaration for each such variable.

(Note that this occurred only for variables declared "varchar"
or "bytea", which may help explain how it escaped detection
for so long.)

Andrey Sokolov

Discussion: https://postgr.es/m/942241662288242@mail.yandex.ru
Fix MSVC warning in compat_informix/rnull.pgc 2022-08-31T16:31:22+00:00 Andres Freund andres@anarazel.de 2022-08-31T16:31:22+00:00 483ac6476198c66696b725d49aa42290a9a94a95 Building the ecpg tests with MSVC, with warnings enabled, results in the following warning: src/interfaces/ecpg/test/compat_informix/rnull.pgc(19,1): warning C4305: 'initializing': truncation from 'double' to 'float' The more obvious fix would be an 'f' suffix, but ecpg can't parse that. Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com> Discussion: https://postgr.es/m/2180a97c-c026-1b6c-cec8-d6e499f97017@enterprisedb.com 
Building the ecpg tests with MSVC, with warnings enabled, results in the
following warning:
src/interfaces/ecpg/test/compat_informix/rnull.pgc(19,1): warning C4305: 'initializing': truncation from 'double' to 'float'

The more obvious fix would be an 'f' suffix, but ecpg can't parse that.

Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/2180a97c-c026-1b6c-cec8-d6e499f97017@enterprisedb.com
Fix ECPG's handling of type names that match SQL keywords. 2022-07-12T21:05:46+00:00 Tom Lane tgl@sss.pgh.pa.us 2022-07-12T21:05:46+00:00 83f1c7b742e80d5aa15e6710ecb324e388d007b3 Previously, ECPG could only cope with variable declarations whose type names either weren't any SQL keyword, or were at least partially reserved. If you tried to use something in the unreserved_keyword category, you got a syntax error. This is pretty awful, not only because it says right on the tin that those words are not reserved, but because the set of such keywords tends to grow over time. Thus, an ECPG program that was just fine last year could fail when recompiled with a newer SQL grammar. We had to work around this recently when STRING became a keyword, but it's time for an actual fix instead of a band-aid. To fix, borrow a trick from C parsers and make the lexer's behavior change when it sees a word that is known as a typedef. This is not free of downsides: if you try to use such a name as a SQL keyword in EXEC SQL later in the program, it won't be recognized as a SQL keyword, leading to a syntax error there instead. So in a real sense this is just trading one hazard for another. But there is an important difference: with this, whether your ECPG program works depends only on what typedef names and SQL commands are used in the program text. If it compiles today it'll still compile next year, even if more words have become SQL keywords. Discussion: https://postgr.es/m/3661437.1653855582@sss.pgh.pa.us 
Previously, ECPG could only cope with variable declarations whose
type names either weren't any SQL keyword, or were at least partially
reserved.  If you tried to use something in the unreserved_keyword
category, you got a syntax error.

This is pretty awful, not only because it says right on the tin that
those words are not reserved, but because the set of such keywords
tends to grow over time.  Thus, an ECPG program that was just fine
last year could fail when recompiled with a newer SQL grammar.
We had to work around this recently when STRING became a keyword,
but it's time for an actual fix instead of a band-aid.

To fix, borrow a trick from C parsers and make the lexer's behavior
change when it sees a word that is known as a typedef.  This is not
free of downsides: if you try to use such a name as a SQL keyword
in EXEC SQL later in the program, it won't be recognized as a SQL
keyword, leading to a syntax error there instead.  So in a real
sense this is just trading one hazard for another.  But there is an
important difference: with this, whether your ECPG program works
depends only on what typedef names and SQL commands are used in the
program text.  If it compiles today it'll still compile next year,
even if more words have become SQL keywords.

Discussion: https://postgr.es/m/3661437.1653855582@sss.pgh.pa.us
Improved ECPG warning as suggested by Michael Paquier and removed test case 2021-08-17T13:01:09+00:00 Michael Meskes meskes@postgresql.org 2021-08-17T12:58:33+00:00 f576de1db1eeca63180b1ffa4b42b1e360f88577 that triggers the warning during regression tests. 
that triggers the warning during regression tests.
Fix connection handling for DEALLOCATE and DESCRIBE statements 2021-08-13T08:45:08+00:00 Michael Meskes meskes@postgresql.org 2021-08-13T08:34:04+00:00 399edafa2aba562a8013fbe039f3cbf3a41a436e After binding a statement to a connection with DECLARE STATEMENT the connection was still not used for DEALLOCATE and DESCRIBE statements. This patch fixes that, adds a missing warning and cleans up the code. Author: Hayato Kuroda Reviewed-by: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/TYAPR01MB5866BA57688DF2770E2F95C6F5069%40TYAPR01MB5866.jpnprd01.prod.outlook.com 
After binding a statement to a connection with DECLARE STATEMENT the connection
was still not used for DEALLOCATE and DESCRIBE statements. This patch fixes
that, adds a missing warning and cleans up the code.

Author: Hayato Kuroda
Reviewed-by: Kyotaro Horiguchi, Michael Paquier
Discussion: https://postgr.es/m/TYAPR01MB5866BA57688DF2770E2F95C6F5069%40TYAPR01MB5866.jpnprd01.prod.outlook.com