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.
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.
#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>
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>
compatibility. There isn't much difference here against my previous
PQprint() code, except that you can add optional arguments to the
<table args> in html.
Most of the changes in here look to b epurely cosmetic, and don't
affect anything...
...and some stuff is completely questionable...in that I may have reversed
some of the stuf fwe already had :(
before (plus some optimisations/bug fixes et al). I've included a small
demo transcript below. Note that all of of the display
functionality/intelligence you see here, can be had merely by calling
the new LIBPQ PQprint() routine with the appropriate arguments/options,
including the HTML3 output guff.
submitted by: Julian Assange <proff@suburbia.net>
