Thread: pgsql-server/ oc/src/sgml/libpq.sgml oc/src/sg ...

pgsql-server/ oc/src/sgml/libpq.sgml oc/src/sg ...

From
tgl@postgresql.org (Tom Lane)
Date:
CVSROOT:    /cvsroot
Module name:    pgsql-server
Changes by:    tgl@postgresql.org    03/04/21 20:08:07

Modified files:
    doc/src/sgml   : libpq.sgml protocol.sgml
    src/backend/access/common: printtup.c
    src/backend/commands: async.c copy.c
    src/backend/libpq: auth.c pqcomm.c pqformat.c
    src/backend/postmaster: postmaster.c
    src/backend/tcop: dest.c fastpath.c postgres.c
    src/backend/utils/error: elog.c
    src/include/libpq: pqcomm.h pqformat.h
    src/interfaces/libpq: fe-connect.c fe-exec.c fe-misc.c
                          libpq-int.h
    src/test/regress/expected: alter_table.out copy2.out domain.out

Log message:
    Another round of protocol changes.  Backend-to-frontend messages now all
    have length words.  COPY OUT reimplemented per new protocol: it doesn't
    need \. anymore, thank goodness.  COPY BINARY to/from frontend works,
    at least as far as the backend is concerned --- libpq's PQgetline API
    is not up to snuff, and will have to be replaced with something that is
    null-safe.  libpq uses message length words for performance improvement
    (no cycles wasted rescanning long messages), but not yet for error
    recovery.


Re: pgsql-server/ oc/src/sgml/libpq.sgml oc/src/sg ...

From
"Christopher Kings-Lynne"
Date:
> Another round of protocol changes.  Backend-to-frontend messages now all
> have length words.  COPY OUT reimplemented per new protocol: it doesn't
> need \. anymore, thank goodness.

What are the backwards compatibility issues with that particular change?

Chris


Re: pgsql-server/ oc/src/sgml/libpq.sgml oc/src/sg ...

From
Tom Lane
Date:
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> Another round of protocol changes.  Backend-to-frontend messages now all
>> have length words.  COPY OUT reimplemented per new protocol: it doesn't
>> need \. anymore, thank goodness.

> What are the backwards compatibility issues with that particular change?

None, it's hidden by libpq: PQgetline manufactures a "\." at end of data.

The PQgetline API is pretty sucky anyway and will be deprecated once the
dust settles, but apps that use it will be no more nor less broken than
they were before ...

            regards, tom lane