1. Rewritten libpq to allow asynchronous clients.

2. Implemented client side of cancel protocol in library,
   and patched psql.c to send a cancel request upon SIGINT.  The
   backend doesn't notice it yet :-(

3. Implemented 'Z' protocol message addition and renaming of
   copy in/out start messages.  These are implemented conditionally,
   ie, the client protocol version is checked; so the code should
   still work with 1.0 clients.

4. Revised protocol and libpq sgml documents (don't have an SGML
   compiler, though, so there may be some markup glitches here).


What remains to be done:

1. Implement addition of atttypmod field to RowDescriptor messages.
   The client-side code is there but ifdef'd out.  I have no idea
   what to change on the backend side.  The field should be sent
   only if protocol >= 2.0, of course.

2. Implement backend response to cancel requests received as OOB
   messages.  (This prolly need not be conditional on protocol
   version; just do it if you get SIGURG.)

3. Update libpq.3.  (I'm hoping this can be generated mechanically
   from libpq.sgml... if not, will do it by hand.)  Is there any
   other doco to fix?

4. Update non-libpq interfaces as necessary.  I patched libpgtcl
   so that it would compile, but haven't tested it.  Dunno what
   needs to be done with the other interfaces.

Have at it!

Tom Lane

If PQfn() receives NOTICEs from the backend, it fails because there is no
provision to deal with them.

This patch (supplied by Anders Hammarquist <iko@netg.se> to me as Debian
maintainer of postgresql) cures the problem:

The following patch is to src/interfaces/libpq of postgresql-6.3.
The purpose of the patch is to make the initialization of
const char *pgresStatus[] match the ExecStatusType enum.

I've completed the patch to fix the protocol and authentication issues I
was discussing a couple of weeks ago.  The particular changes are:

- the protocol has a version number
- network byte order is used throughout
- the pg_hba.conf file is used to specify what method is used to
  authenticate a frontend (either password, ident, trust, reject, krb4
  or krb5)
- support for multiplexed backends is removed
- appropriate changes to man pages
- the -a switch to many programs to specify an authentication service
  no longer has any effect
- the libpq.so version number has changed to 1.1

The new backend still supports the old protocol so old interfaces won't
break.

 Most processors should optimize this a bit better wrt cache prefetch.

Document pg_dump -z, clean up option list.  Fix problem with libpq handling of field names uppercase code.

Another PGINDENT run that changes variable indenting and case label indenting.  Also static variable indenting.

Subject: [PATCHES] memory leak patches in libpq and psql

A couple of small memory leak patches (detected with Purify) primarily
in libpq.

* Fixed (NULL) border problem in psql (run psql, do \m, then select
  something from a table...row separators will be nulls)
* Fixed memory leak with the abovementioned border not being freed
  properly.
* Fixed memory leak in freePGconn() not freeing conn->port
* Fixed up PQclear() to free parts of PGresult only if these
  parts are not null.
* Fixed a decent memory leak that occured after executing every command
  in psql. PGresult *results was not freed most of the time.

There is still a leak being detected (2 bytes) in readline functions, but
I think this is old readline library. I will install new one and test it.

Made PQsetdb() and PQfnumber() case-insensitive.
Removed attempt to set table ownership via pg_dumpall.

#if defined(aix)
#define TERMIOS_H_LOCATION <termios.h>
#else
#define TERMIOS_H_LOCATION <sys/termios.h>
#endif

libpq/fe-exec.c modified so that location of termios.h is determined
by whether HAVE_TERMIOS_H is defined or not, in preparation for switch
to configure

Hi,

    counting the empty dummy queries in libpq isn't everything.
    If the backend sends an error, the I returns from the dummies
    still come. So we must eat them up in any case, not just
    returning on the occurence of an E reply.

Until later, Jan

    PQexec  handles  the possibility of multiple results from one
    query by simply submitting an empty  query  after  the  first
    result and waiting for an 'I' message.

    Rules  can  generate  errors with transaction abort after the
    first 'C' message was recieved (e.g. if a C-language function
    used  in  a rule calls elog(WARN, ...)). Thus we have to look
    for.

Jan(wieck@sapserv.debis.de)

Async notifies received while a backend is in the middle of a begin/end
transaction block are lost by libpq when the final end command is issued.

The bug is in the routine PQexec of libpq. The routine throws away any
message from the backend when a message of type 'C' is received. This
type of message is sent when the result of a portal query command with
no tuples is returned. Unfortunately this is the case of the end command.
As all async notification are sent only when the transaction is finished,
if they are received in the middle of a transaction they are lost in the
libpq library. I added some tracing code to PQexec and this is the output:

Submitted by: Massimo Dal Zotto <dz@cs.unitn.it>

|Here is a fix for the psql alignment problem.  It turns out that libpq
|was trying to determine if the column contained only numeric values so
|it could right justify it.  The 'e' values were taked as exponient
|values and all columns were considered numeric.
|
|The patch excludes 'e' and 'E' as being valid first-column numeric
|values.
|

Submitted by: Bruce...

|We're all too familiar with psql's "no response from backend" message.
|Users can't tell what this means, and psql continues prompting for
|commands after it even though the backend is dead and no commands can
|succeed.  It eventually dies on a signal when the dead socket fills
|up.  I extended the message to offer a better explanation and made
|psql exit when it finds the backend is dead.
|
|I also added a short message and newline when the user does a ctl-D so
|it doesn't mess up the terminal display.
|
|

Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net>

Attached is a patch to allow libpq to determine if a field is null.

This is needed because text fields will return a PQgetlength() of 0
whether it is '' or NULL.  There is even a comment in the source noting
the fact.

I have changed the value of the 'len' field for NULL result fields.  If
the field is null, the len is set to -1 (NULL_LEN).  I have changed
PQgetlength() to return a 0 length for both '' and NULL.  A new function
PQgetisnull() returns true or false for NULL.

The only risk is to applications that do not use the suggested
PQgetlength() call, but read the result 'len' field directly.

As this is not recommended, I think we are safe here.

A separate documentation patch will be sent.


Submitted by: Bruce Momjian <maillist@candle.pha.pa.us>

Submitted by: darcy@druid.druid.com (D'Arcy J.M. Cain)

Here are a few minor fixes to Postgres95.  Mostly I have added const
to some of the char pointers.  There was also a missing header file
and a place where it looks like "==" was used when "=" was meant.
I also changed some variables from Pfin and Pfout tp pfin and pfout
because the latter shadow global variables and that just seems like
an unsafe practice which I like to avoid.

Submitted by:  "D'Arcy J.M. Cain" <darcy@druid.druid.com>

#include <sys/termios.h>

Submitted by: Dr. George