pgsql: Remove duplicate name from list of acknowledgments

Remove duplicate name from list of acknowledgments Reported-by: m.zhi...@postgrespro.ru Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/df80b1d6cd36c6cc6be7529895c0434e90e911cc Modified Files -- doc/src/sgml/release-17.sgml | 1 - 1 file changed,

pgsql: Correct name in list of acknowledgments

Correct name in list of acknowledgments Reported-by: Etsuro Fujita Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/47b92f8fc522d3c1a75a955c32c492d752316584 Modified Files -- doc/src/sgml/release-17.sgml | 2 +- 1 file changed, 1 insertion(+), 1 d

pgsql: Define PG_LOGICAL_DIR for path pg_logical/ in data folder

Define PG_LOGICAL_DIR for path pg_logical/ in data folder This is similar to 2065ddf5e34c, but this time for pg_logical/ itself and its contents, like the paths for snapshots, mappings or origin checkpoints. Author: Bertrand Drouvot Reviewed-by: Ashutosh Bapat, Yugo Nagata, Michael Paquier Discus

pgsql: Define PG_REPLSLOT_DIR for path pg_replslot/ in data folder

Define PG_REPLSLOT_DIR for path pg_replslot/ in data folder This commit replaces most of the hardcoded values of "pg_replslot" by a new PG_REPLSLOT_DIR #define. This makes the style more consistent with the existing PG_STAT_TMP_DIR, for example. More places will follow a similar change. Author:

pgsql: Rename pg_sequence_read_tuple() to pg_get_sequence_data()

Rename pg_sequence_read_tuple() to pg_get_sequence_data() This commit removes log_cnt from the tuple returned by the SQL function. This field is an internal counter that tracks when a WAL record should be generated for a sequence, and it is reset each time the sequence is restored or recovered. I

pgsql: Fix mis-deparsing of ORDER BY lists when there is a name conflic

Fix mis-deparsing of ORDER BY lists when there is a name conflict. If an ORDER BY item in SELECT is a bare identifier, the parser first seeks it as an output column name of the SELECT (for SQL92 compatibility). However, ruleutils.c is expecting the SQL99 interpretation where such a name is an inp

pgsql: Fix mis-deparsing of ORDER BY lists when there is a name conflic

Fix mis-deparsing of ORDER BY lists when there is a name conflict. If an ORDER BY item in SELECT is a bare identifier, the parser first seeks it as an output column name of the SELECT (for SQL92 compatibility). However, ruleutils.c is expecting the SQL99 interpretation where such a name is an inp

pgsql: Fix mis-deparsing of ORDER BY lists when there is a name conflic

Fix mis-deparsing of ORDER BY lists when there is a name conflict. If an ORDER BY item in SELECT is a bare identifier, the parser first seeks it as an output column name of the SELECT (for SQL92 compatibility). However, ruleutils.c is expecting the SQL99 interpretation where such a name is an inp

Re: pgsql: Restrict accesses to non-system views and foreign tables during

On Thu, Aug 29, 2024 at 7:29 AM Peter Eisentraut wrote: > > On 27.08.24 22:02, Masahiko Sawada wrote: > > On Tue, Aug 27, 2024 at 6:29 AM Tom Lane wrote: > >> > >> Peter Eisentraut writes: > >>> Maybe in the documentation it would also be appropriate to mention that > >>> this is meant to be use

pgsql: Message style improvements

Message style improvements Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f2353dd71724c0d18d5912e105f034b50494bfe9 Modified Files -- src/backend/access/transam/varsup.c| 6 +-- src/backend/access/transam/xact.c |

pgsql: Message style improvements

Message style improvements Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/edee0c621de6f334c94c0ed8649d31ceba7401c8 Modified Files -- src/backend/access/transam/varsup.c| 6 +-- src/backend/access/transam/xact.c | 2 +- s

Re: pgsql: Restrict accesses to non-system views and foreign tables during

On 27.08.24 22:02, Masahiko Sawada wrote: On Tue, Aug 27, 2024 at 6:29 AM Tom Lane wrote: Peter Eisentraut writes: Maybe in the documentation it would also be appropriate to mention that this is meant to be used by pg_dump, not for general use -- unless it is? I'd vote against that. I thi

pgsql: Put generated_stored test objects in a schema

Put generated_stored test objects in a schema This avoids naming conflicts with concurrent tests with similarly named objects. Currently, there are none, but a tests for virtual generated columns are planned to be added. Reviewed-by: Corey Huinker Reviewed-by: Tomasz Rybak Discussion: https:/

pgsql: Rename regress test generated to generated_stored

Rename regress test generated to generated_stored This makes naming room to have another test file for virtual generated columns. Reviewed-by: Corey Huinker Reviewed-by: Tomasz Rybak Discussion: https://www.postgresql.org/message-id/flat/a368248e-69e4-40be-9c07-6c3b5880b...@eisentraut.org Bra

pgsql: Disallow USING clause when altering type of generated column

Disallow USING clause when altering type of generated column This does not make sense. It would write the output of the USING clause into the converted column, which would violate the generation expression. This adds a check to error out if this is specified. There was a test for this, but that

pgsql: Disallow USING clause when altering type of generated column

Disallow USING clause when altering type of generated column This does not make sense. It would write the output of the USING clause into the converted column, which would violate the generation expression. This adds a check to error out if this is specified. There was a test for this, but that

pgsql: Disallow USING clause when altering type of generated column

Disallow USING clause when altering type of generated column This does not make sense. It would write the output of the USING clause into the converted column, which would violate the generation expression. This adds a check to error out if this is specified. There was a test for this, but that

pgsql: Disallow USING clause when altering type of generated column

Disallow USING clause when altering type of generated column This does not make sense. It would write the output of the USING clause into the converted column, which would violate the generation expression. This adds a check to error out if this is specified. There was a test for this, but that

pgsql: Disallow USING clause when altering type of generated column

Disallow USING clause when altering type of generated column This does not make sense. It would write the output of the USING clause into the converted column, which would violate the generation expression. This adds a check to error out if this is specified. There was a test for this, but that

pgsql: Disallow USING clause when altering type of generated column

Disallow USING clause when altering type of generated column This does not make sense. It would write the output of the USING clause into the converted column, which would violate the generation expression. This adds a check to error out if this is specified. There was a test for this, but that

pgsql: Disallow USING clause when altering type of generated column

Disallow USING clause when altering type of generated column This does not make sense. It would write the output of the USING clause into the converted column, which would violate the generation expression. This adds a check to error out if this is specified. There was a test for this, but that

pgsql: Refactor lock manager initialization to make it a bit less speci

Refactor lock manager initialization to make it a bit less special Split the shared and local initialization to separate functions, and follow the common naming conventions. With this, we no longer create the LockMethodLocalHash hash table in the postmaster process, which was always pointless. Re

pgsql: Rename some shared memory initialization routines

Rename some shared memory initialization routines To make them follow the usual naming convention where FoobarShmemSize() calculates the amount of shared memory needed by Foobar subsystem, and FoobarShmemInit() performs the initialization. I didn't rename CreateLWLocks() and InitShmmeIndex(), bec