pgsql: ecpg: Avoid C99-ism in newly-added test for Oracle compat

ecpg: Avoid C99-ism in newly-added test for Oracle compat Per buildfarm member mylodon. As C99 declarations are allowed in v12~, this is adjusted only on REL_11_STABLE. Introduced by 9eb44bb. Branch -- REL_11_STABLE Details ---

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

ecpg: Fix handling of strings in ORACLE compat code with SQLDA 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

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

ecpg: Fix handling of strings in ORACLE compat code with SQLDA 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

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

ecpg: Fix handling of strings in ORACLE compat code with SQLDA 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

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

ecpg: Fix handling of strings in ORACLE compat code with SQLDA 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

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

ecpg: Fix handling of strings in ORACLE compat code with SQLDA 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

pgsql: ecpg: Fix handling of strings in ORACLE compat code with SQLDA

ecpg: Fix handling of strings in ORACLE compat code with SQLDA 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

pgsql: Fix some typos and some incorrectly duplicated words

Fix some typos and some incorrectly duplicated words Author: Justin Pryzby Reviewed-by: David Rowley Discussion: https://postgr.es/m/zd3d1qxoccnn8...@telsasoft.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/eef231e8161eb8031a928fe48134ef25ab81fe5e Modified

pgsql: Fix various typos

Fix various typos This fixes many spelling mistakes in comments, but a few references to invalid parameter names, function names and option names too in comments and also some in string constants Also, fix an #undef that was undefining the incorrect definition Author: Alexander Lakhin

Re: pgsql: Add grantable MAINTAIN privilege and pg_maintain role.

On Sat, 2023-04-15 at 20:47 +0200, Peter Eisentraut wrote: > This commit removed RangeVarCallbackOwnsTable(), but there is still a > mention of it in a comment in src/backend/commands/tablecmds.c.  > Maybe > that mention can simply be removed, or the comment rephrased. Thank you, fixed. --

pgsql: Comment fix for 60684dd834.

Comment fix for 60684dd834. Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/766f3799-0269-162f-ba63-4cae34a55...@enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e39d512f3e9b1e34ffba77c8fe120c2675f6873b Modified Files --

Re: pgsql: Further cleanup of autoconf output files for GSSAPI changes.

Andrew Dunstan writes: > On 2023-04-17 Mo 15:53, Tom Lane wrote: >> (This three-build-system business can't go away soon enough.) > From my POV we can remove it any time - I am still having Windows > issues with meson, but only with MSYS2. The MSVC meson build on drongo > is perfectly well

Re: pgsql: Further cleanup of autoconf output files for GSSAPI changes.

On 2023-04-17 Mo 15:53, Tom Lane wrote: Andrew Dunstan writes: I think this also needs a fix in src/tools/msvc/Solution.pm, see Argh, forgot about that. Will fix. (This three-build-system business

pgsql: Update Solution.pm for HAVE_GSSAPI[_GSSAPI]_EXT_H, too.

Update Solution.pm for HAVE_GSSAPI[_GSSAPI]_EXT_H, too. Commit d48ac0070 was still a brick shy of a load. Per buildfarm (via Andrew Dunstan). Discussion: https://postgr.es/m/08dd6053-deee-52e9-954b-eb6923290...@dunslane.net Branch -- master Details ---

Re: pgsql: Further cleanup of autoconf output files for GSSAPI changes.

Andrew Dunstan writes: > I think this also needs a fix in src/tools/msvc/Solution.pm, see > Argh, forgot about that. Will fix. (This three-build-system business can't go away soon enough.)

Re: pgsql: Further cleanup of autoconf output files for GSSAPI changes.

On 2023-04-17 Mo 11:22, Tom Lane wrote: Further cleanup of autoconf output files for GSSAPI changes. Running autoheader was missed in f7431bca8. This is cosmetic since we aren't using these HAVE_ symbols, but let's get everything in sync while we're looking at this.

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

Avoid trying to write an empty WAL record in log_newpage_range(). If the last few pages in the specified range are empty (all zero), then log_newpage_range() could try to emit an empty WAL record containing no FPIs. This at least upsets an Assert in ReserveXLogInsertLocation, and might perhaps

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

Avoid trying to write an empty WAL record in log_newpage_range(). If the last few pages in the specified range are empty (all zero), then log_newpage_range() could try to emit an empty WAL record containing no FPIs. This at least upsets an Assert in ReserveXLogInsertLocation, and might perhaps

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

Avoid trying to write an empty WAL record in log_newpage_range(). If the last few pages in the specified range are empty (all zero), then log_newpage_range() could try to emit an empty WAL record containing no FPIs. This at least upsets an Assert in ReserveXLogInsertLocation, and might perhaps

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

Avoid trying to write an empty WAL record in log_newpage_range(). If the last few pages in the specified range are empty (all zero), then log_newpage_range() could try to emit an empty WAL record containing no FPIs. This at least upsets an Assert in ReserveXLogInsertLocation, and might perhaps

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

Avoid trying to write an empty WAL record in log_newpage_range(). If the last few pages in the specified range are empty (all zero), then log_newpage_range() could try to emit an empty WAL record containing no FPIs. This at least upsets an Assert in ReserveXLogInsertLocation, and might perhaps

pgsql: Avoid trying to write an empty WAL record in log_newpage_range()

Avoid trying to write an empty WAL record in log_newpage_range(). If the last few pages in the specified range are empty (all zero), then log_newpage_range() could try to emit an empty WAL record containing no FPIs. This at least upsets an Assert in ReserveXLogInsertLocation, and might perhaps

pgsql: Fix incorrect comment about nbtree WAL record.

Fix incorrect comment about nbtree WAL record. The nbtree VACUUM WAL record stores its page offset number payload in blk 0 (just like the closely related nbtree DELETE WAL record). Commit ebd551f5 fixed a similar issue with the DELETE WAL record, but missed this one. Branch -- master

pgsql: Further cleanup of autoconf output files for GSSAPI changes.

Further cleanup of autoconf output files for GSSAPI changes. Running autoheader was missed in f7431bca8. This is cosmetic since we aren't using these HAVE_ symbols, but let's get everything in sync while we're looking at this. Discussion: https://postgr.es/m/2422362.1681741...@sss.pgh.pa.us

pgsql: Update configure for ab969a376

Update configure for ab969a376 Commit ab969a376 updated configure.ac but neglected to update the actual configure script. Fix that. Pointed out by Tom Lane Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ca07a6e7bd2cb1d6ea38a036be8d60e196935428 Modified Files

pgsql: doc: Add additional SQL features codes from SQL:2023

doc: Add additional SQL features codes from SQL:2023 These were mysteriously omitted in c9f57541d9. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1c77de98017022e45a0b12ddb71e202d1f68 Modified Files -- src/backend/catalog/sql_features.txt | 2 ++ 1

pgsql: Update Kerberos/GSSAPI configure/meson check

Update Kerberos/GSSAPI configure/meson check Instead of checking for the much older gss_init_sec_context, check for gss_store_cred_into which was added in MIT Kerberos 1.11 (circa 2012). Discussion: https://postgr.es/m/2313469.1681695223%40sss.pgh.pa.us Branch -- master Details ---

pgsql: Put new command-line option into sensible order in help output

Put new command-line option into sensible order in help output We have two existing conventions for long options: either alphabetical among short options, or all long options after all the short options. But the convention apparently used here, next to a functionally related option, is not one of