postgresql/src/test/modules/libpq_pipeline
Peter Eisentraut 17974ec259 Revise GUC names quoting in messages again
After further review, we want to move in the direction of always
quoting GUC names in error messages, rather than the previous (PG16)
wildly mixed practice or the intermittent (mid-PG17) idea of doing
this depending on how possibly confusing the GUC name is.

This commit applies appropriate quotes to (almost?) all mentions of
GUC names in error messages.  It partially supersedes a243569bf6 and
8d9978a717, which had moved things a bit in the opposite direction
but which then were abandoned in a partial state.

Author: Peter Smith <smithpb2250@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/CAHut%2BPv-kSN8SkxSdoHano_wPubqcg5789ejhCDZAcLFceBR-w%40mail.gmail.com
2024-05-17 11:44:26 +02:00
..
t Update copyright for 2024 2024-01-03 20:49:05 -05:00
traces Support retrieval of results in chunks with libpq. 2024-04-06 20:45:11 -04:00
.gitignore Implement pipeline mode in libpq 2021-03-15 18:13:42 -03:00
Makefile Add Windows file version information to libpq_pipeline.exe. 2021-06-01 18:04:15 -07:00
README 001_libpq_pipeline.pl: use Test::Differences if available 2023-03-08 18:31:55 +01:00
libpq_pipeline.c Revise GUC names quoting in messages again 2024-05-17 11:44:26 +02:00
meson.build Update copyright for 2024 2024-01-03 20:49:05 -05:00

README

Test programs and libraries for libpq

If you have Test::Differences installed, any differences in the trace files
are displayed in a format that's easier to read than the standard format.
=====================================

This module was developed to test libpq's "pipeline" mode, but it can
be used for any libpq test that requires specialized C code.

"make check" will run all the tests in the module against a temporary
server installation.

You can manually run a specific test by running:

    ./libpq_pipeline <name of test> [ <connection string> ]

This will not start a new server, but rather connect to the server
specified by the connection string, or your default server if you
leave that out.  To discover the available test names, run:

    ./libpq_pipeline tests

To add a new test to this module, you need to edit libpq_pipeline.c.
Add a function to perform the test, and arrange for main() to call it
when the name of your new test is passed to the program.  Don't forget
to add the name of your test to the print_test_list() function, else
the TAP test won't run it.

If the order in which Postgres protocol messages are sent is deterministic
in your test, you should arrange for the message sequence to be verified
by the TAP test.  First generate a reference trace file, using a command
like:

   ./libpq_pipeline -t traces/mynewtest.trace mynewtest

Then add your test's name to the list in the $cmptrace definition in the
t/001_libpq_pipeline.pl file.  Run "make check" a few times to verify
that the trace output actually is stable.