test: parametrize transaction tests with pipeline on/off

The 'conn' fixture is overloaded in transaction tests, pulling the
'pipeline' fixture to have them run with or without a pipeline.

When checking for connection's transaction state, just after entering
the transaction() block (e.g. in test_basic), we need to sync the
pipeline in order to get the state right. This is just for tests as the
exact transaction state, in pipeline mode, is not deterministic since
query results are not fetched directly.

The following tests fail:

  tests/test_transaction.py::test_basic[pipeline=on]
  tests/test_transaction.py::test_begins_on_enter[pipeline=on]
  tests/test_transaction.py::test_commit_on_successful_exit[pipeline=on]
  tests/test_transaction.py::test_rollback_on_exception_exit[pipeline=on]
  tests/test_transaction.py::test_autocommit_off_but_no_tx_started_successful_exit[pipeline=on]
  tests/test_transaction.py::test_autocommit_off_but_no_tx_started_exception_exit[pipeline=on]
  tests/test_transaction.py::test_nested_all_changes_persisted_on_successful_exit[pipeline=on]
  tests/test_transaction.py::test_nested_all_changes_discarded_on_outer_exception[pipeline=on]
  tests/test_transaction.py::test_nested_all_changes_discarded_on_inner_exception[pipeline=on]
  tests/test_transaction.py::test_nested_inner_scope_exception_handled_in_outer_scope[pipeline=on]
  tests/test_transaction.py::test_nested_three_levels_successful_exit[pipeline=on]
  tests/test_transaction.py::test_named_savepoints_successful_exit[pipeline=on]
  tests/test_transaction.py::test_explicit_rollback_of_enclosing_tx_outer_tx_unaffected[pipeline=on]
  tests/test_transaction.py::test_str[pipeline=on]

This is because the connection state is not correct at the end of
transaction, we'll fix this in next commit.

Some others were adjusted as follows:

* when entering the transaction() block, e.g. in test_begins_on_enter,
  we eventually call pipeline.sync() in order to get the state right
  (this is just for tests as the exact transaction state, in pipeline
  mode, is not deterministic since query results are not fetched
  directly);

* test_context_inerror_rollback_no_clobber[pipeline=on] is skipped, as
  explained in comment inline;

* test_prohibits_use_of_commit_rollback_autocommit[pipeline=on] is
  xfail, because Connection._check_intrans() does not check for pipeline
  mode (see TODO inline about a possible solution);

* test_str now checks for [<txstatus>, pipeline=ON] in str(Transaction).

test: add fixtures to toggle pipeline mode

Also add a pytest mark so that one can run 'pytest -m pipeline' to
select all pipeline-mode tests.

feat: display the pipeline status in the objects repr

chore: bump version to release 3.0.13

Merge branch 'fix-296'

docs: suggest to use commit to maintain atomic sanity in pipeline mode

fix: fix integration between pipelines and nested transaction

Refactor to remove all the knowledge about pipelines from the
transaction object. Replaced by just syncing before entering the
transaction.

Had to drop the pipeline exit, which will now fetch results whatever the
level. If not doing so, a final sync should have been forced to exit
with a clean state from an inner transaction block.

test: fix test of pipeline mode and nested transaction

This test fails in the current implementation.

test: drop TODO points and emergency rollbacks from pipeline tests

The previous changeset restored some sanity. The behaviour in
`test_errors_raised_on_commit` is not inconsistent with the non-pipeline
mode because the two are not comparable: in non-pipeline mode the
exception is raised by `execute()`, not by `commit()`. If an exception
is raised in `commit()` itself, it is already handled consistently, as
`test_error_on_commit` shows.

fix: wrap transaction in pipelines if the connection has one

When entering a transaction on a connection in pipeline mode, we open an
inner pipeline to ensure that a Sync is emitted at the end of
transaction thus restoring the connection in its expected state (i.e.
the same as in non-pipeline mode).

test: add test to verify the behaviour of failed commits

The exception is raised where expected; the transaction is left in IDLE
state. This is unlike what happens in pipeline mode.

fix: fix Transaction commit in pipeline mode

Make sure we receive the commit message, so we can raise an immediate
exception, as we do for connection-handled transactions.

Highlight, in the test, a behaviour difference between commit in
pipeline and non-pipeline mode. In the latter, after a failed commit,
the connection is left IDLE; in pipeline mode it is left INERROR so we
need a further rollback to keep on using it. Will look if this can be
made consistent.

fix: fix nested transaction entering in pipeline mode

If the connection is idle, it might be that we are missing results.
Receive them to align the connection state to what the transaction
object expects, otherwise the assert in _push_savepoint() will fail.

fix: sync the pipeline on commit()

This maintains the expectation that, after commit(), the operation is
really persisted. As per postgres pipeline docs:

    The client must not assume that work is committed when it sends a
    COMMIT — only when the corresponding result is received to confirm the
    commit is complete.

With this change we are effectively receiving the result of the commit,
eventually throwing an exception if it happened.

Close #296

fix: fetch results on Pipeline.sync().

This allows a sync() call to establish an high level synchronization
point between the application and the server. If there were errors in
the processing so far, sync will throw the exception.

See #296.

docs: add warning about error messages raised randomly in pipeline mode

Close #266

fix: raise a clean error on pipeline() on a closed connection

chore: update cibuildwheel to 2.5.0

Merge branch 'fix-293'

Fix array oid dumping lists of integer

The problem was only in the list text dumper, which was trying to do more
than what needed. The list binary dumper worked alright.

Drop mixed array test, which don't really represent anything Postgres
can work with.

Close #293

test: add test to verify the wrong array oid with numbers

The array binary dumper does the right thing; the text one picks
numeric[] unconditionally. It was clearly made on purpose, but #293
shows that it's a bad idea.

docs: wordsmith pipeline docs

docs: drop repeated sentence

Merge branch 'pipeline-docs'

docs: typo fixed

Thank you @dlax!

docs: add examples and messages details in pipeline mode

docs: mention that conn.pipeline() yields a Pipeline object

While reading the section, it is otherwise not obvious to understand
where to get the Pipeline object from.

docs: add note about implicit transactions and sync in pipeline mode

docs: split/reshuffle pipeline docs

- Postgres concept
- Psycopg usage
- detail about sync points
- disclaimer - don't call the semver police.

docs: document that now rollback issues a sync point

docs: add warning disclaimer about pipeline mode

docs: clarify flush and sync pipeline operations

docs: fix pipeline docs typos

docs: add note about features not supported in pipeline mode

docs: add first cut of pipeline mode docs

fix: sync pipeline state on rollback

Merge branch 'pipeline-sync-no-fetch'

feat: only Sync nested pipelines at exit

It's not needed to force a results fetch when exiting a nested pipeline
as this would naturally happen either later in the outer pipeline or
eventually at the end of the outermost one. Rather, just do a Sync, as
it allows outer pipeline to resume normal execution in case the inner
one got into aborted state.

fix: only request a pipeline flush in returning executemany()

A full Sync is not needed as we're only interested in getting results
when returning=True.

fix: do not fetch in Pipeline.sync()

During previous refactorings, we made Pipeline.sync() also fetch results
from the server. But this somehow breaks the semantics of the
synchronization point as defined by Postgres because the user might be
interested in emitting Sync message as a way to solely close the current
series of queries in the pipeline: i.e., flush queries from client to
server and reset the pipeline error state. In this respect, the 'fetch'
step should be explicit.

BasePipeline._sync_gen() is changed to only emit a Sync and a new
_exit_gen() method is introduced doing what _sync_gen() previously did.
Accordingly, the warning emitted when calling this _exit_gen() at
pipeline exit is adjusted to say "terminating" instead of "syncing".

fix: shorten tracebacks on pipeline sync and exit

The details shown are only the communication bowels. So we go from:

    Traceback (most recent call last):
      File "trace.py", line 301, in <module>
        conn.execute("select pg_sleep(0.2)")
      File "/usr/lib/python3.8/contextlib.py", line 120, in __exit__
        next(self.gen)
      File "/home/piro/dev/psycopg3/psycopg/psycopg/connection.py", line 881, in pipeline
        yield pipeline
      File "/home/piro/dev/psycopg3/psycopg/psycopg/_pipeline.py", line 197, in __exit__
        self.sync()
      File "/home/piro/dev/psycopg3/psycopg/psycopg/_pipeline.py", line 183, in sync
        self._conn.wait(self._sync_gen())
      File "/home/piro/dev/psycopg3/psycopg/psycopg/connection.py", line 896, in wait
        return waiting.wait(gen, self.pgconn.socket, timeout=timeout)
      File "/home/piro/dev/psycopg3/psycopg/psycopg/waiting.py", line 237, in wait_epoll
        s = gen.send(ready)
      File "/home/piro/dev/psycopg3/psycopg/psycopg/_pipeline.py", line 92, in _sync_gen
        yield from self._communicate_gen()
      File "/home/piro/dev/psycopg3/psycopg/psycopg/_pipeline.py", line 105, in _communicate_gen
        self._process_results(queued, results)
      File "/home/piro/dev/psycopg3/psycopg/psycopg/_pipeline.py", line 149, in _process_results
        raise e.error_from_result(result, encoding=pgconn_encoding(self.pgconn))
    psycopg.errors.UndefinedColumn: column "foo" does not exist
    LINE 1: select foo
                   ^

to:

    Traceback (most recent call last):
      File "trace.py", line 301, in <module>
        conn.execute("select pg_sleep(0.2)")
      File "/usr/lib/python3.8/contextlib.py", line 120, in __exit__
        next(self.gen)
      File "/home/piro/dev/psycopg3/psycopg/psycopg/connection.py", line 881, in pipeline
        yield pipeline
      File "/home/piro/dev/psycopg3/psycopg/psycopg/_pipeline.py", line 205, in __exit__
        raise exc2.with_traceback(None)
    psycopg.errors.UndefinedColumn: column "foo" does not exist
    LINE 1: select foo
                   ^

which shows much more clearly that the traceback was raised at pipeline
block exit.

fix: allow to use cancel() on a closed connection

docs: add hint about using add_signal_handler() to interrupt async queries

Courtesy @gjcarneiro, thank you!

Merge branch 'fix-286'

perf: avoid unnecessary recvfrom() in cursor.stream()

Call PQisBusy() before PQconsumeInput() on fetching results. If not
busy, don't call PQconsumeInput() at all but just go to fetching results
and notifications.

This is especially useful in single-row mode because most of the times
the libpq can produce several results after a single network fetch.
Previously we were calling PQconsumeInput() also when results were
already on the client and there was nothing new to read, which forced
the libpq to run a select() to tell apart a lack of data from an EOF,
see `the grumble`_, and caused the overhead reported in #286.

Close #286.

.. _the grumble: https://github.com/postgres/postgres/blob/ed57cac84d1c5642737dab1e4c4b8cb4f0c4305f/src/interfaces/libpq/fe-misc.c#L681

test: add cursor.stream() test for empty result sets

Also add a missing async test for results with no column.

refactor: replace an assert with a type: ignore

It's not like we give away opcodes for free here.

refactor: send only once per stream

No need to do it at every row, probably entirely wrong. However this is
not the cause of the slowness reported in #286.

refactor: only clean up the wait() timeout if needed

Often we terminate the iteration at the first item, so no need to select
at all.

Re-export from psycopg._cmodule

test: fix variable scope in ctrl-c test

test: verify ctrl-c in async mode using get_event_loop

test: drop test guard for unsupported Python version

docs: document psycopg 3.0.12 released

docs: improvements to the copy docs

docs: add example of table copy across server

See #285 for a conversation.

docs: document that ticket #254 is fixed in 3.0.12

We can consider this just a bug, not a change of interface. It is
particularly bad because it doesn't allow to pipe a COPY FROM into a
COPY TO.

See https://github.com/psycopg/psycopg/discussions/285#discussioncomment-2663192
for details.

test: add tests to verify copy across tables works

docs: cleanup in types/enums docs

typo fix

Merge branch 'enum'

docs(enum): typo-fix and rephrase

docs(enum): restyle news entry

feat(enum): add mapping override to `register_enum()`

test(enum): drop several hundreds of redundant tests

No need to exhaustively test encodings on ascii data or array properties
tested elsewhere.

refactor(enum): introduce an explicit dump/load mapping

This will allow mapping customization; it is also slightly faster
because it doesn't require data encoding/decoding.

fix(enum): raise DataError in case of labels mismatch on load

A DataError subclass is already raised on mismatch on dump. Be
consistent.

fix(enum): move `enum` arg of register_enum() as third item

This is more consistent with the other register_*() functions and allow
a more natural order of arguments if others must be added (e.g.
mapping).

test(enum): refactor in order to write enum-specific type

They all get created, tests can choose to use only some of them.

test(enum): drop unneeded cursor creation

docs(enum): document the behaviour of unregistered and registered enums

test(enum): add tests to verify the behaviour of unregistered enums

refactor(enum): rename python_type -> enum, enum_labels -> labels on EnumInfo

The previous name were lifted from the composite adapters. However, that
class would have had a more ambiguous "type" attribute, and "types" for
the fields, hence the decision of using "python_" and "fields_" prefix
to disambiguate.

In the enum adapters context, enum is not ambiguous, so a more natural
name seems preferred.

feat(enum): dump enums by keys instead of values

This removes the need for enums to be str-based. It also removes the
asymmetry whereby automatically generated enums were *not* string based,
but pure enums.

refactor: add conn_encoding function

Simplifies the chore of obtaining an encoding from the connection,
defaulting to utf-8 if not available.

test(enum): add test to verify enums work with sql_ascii connections

test(enum): typo fixed

test(enum): more idiomatic sql composition

test(enum): disable Enum random testing

test(enum): added async tests from enums

refactor(enum): removed redundant `EnumDumper.dump` method override

fix(enum): code review fixes

* moved documentation to `docs/basic/adapt.rst`;
* use encoding in `EnumLoader`;
* oid-based dumpers;
* rewritten tests;
* minor fixes.

test(enum): add failing tests to illustrate enum needed improvements

feat: add enum support

fix: fix dumping int enums in text mode, python implementation

The error was hidden by a broken test, failing to test the text mode.

docs: a few clarifications about composite adaptation

fix: drop debug logging left over

doc: add PipelineStatus to 'pq' page

feat: add ConnectionInfo.pipeline_status

docs: clean up a couple of sentences

- New version scheme is "starting from PG 10", not "after PG 10" (also,
  chunky bit moved from docstring to docs as for most other docs).
- The transaction status is of the session, not the server.

Merge branch 'executemany-pipeline'

feat: add PipelineAborted exception

It is a condition that likely will have to be managed, so let's not
clobber it with other OperationalError.

fix: don't fail assert if fetching without result in pipeline mode

The error can be triggered easily by the user. The condition is handled
just naturally by all the methods calling _fetch_pipeline().

fix: consistent sync/exit and error management in pipeline contexts

Don't clobber an exception on exit of the nested block too. In order to
simplify the code, make the pipeline count the number of time it is
entered, and call _exit() only the last time it exits.

Drop assert that we have left pipeline mode leaving the block. If we get
in unrecoverable state, we will have not. By now we should probably just
close the connection; however, leaving it this way is a better
indication that the connection is broken because of something about
pipeline mode; closing it would hide it, and even if we raised a
warning, it would be much easier to miss it than to miss the exceptions
raised in broken state.

fix: forbid COPY in pipeline mode

COPY is not supported. Attempting it puts the connection in
unrecoverable state, with pipeline sync failing and pipeline exit
complaining that there are still results. So let's try to not get in
that state.

fix: restore sending a Sync on block exit but not on executemany end

It was removed a few commits ago, but as Denis suggests, it makes sense
to keep it. Reintroduce it (and test for it), but make sure executemany
doesn't send extra sync.

test: add test to verify the number of roundtrips in pipelined executemany

Add fixture to access the trace data as Python object. I think it's cute <3

test: add fixture to write tests based on libpq trace data

fix: make no-tuple results available after executemany returning

There could be useful info there, if the user asks for it. Now this
doesn't slow down the happy execute path, because the default of
returning is False.

fix: only flush the pipeline after executemany if returning

This has the side effect of breaking rowcount, as before, but can send
many executemany in the same pipeline.

`rowcount` is correct if `returning=True` is set instead, which is a
thing we can at least document, and makes sense: "if you want a result,
you flush the pipeline, dude".