Subject: [HACKERS] Patches for 970316 compilation
I made a small pre-emptive change in the new datetime code to eliminate
calls to infnan(). Hopefully this will make Solaris (and probably other
non-GNUlib) systems happier. Didn't find fe-connect.h in the 970316
distribution, so made one up. Also, one of the test routines needs an
update for the geo-decls.h -> geo_decls.h name change.
Patches appear below...
Subject: [HACKERS] Patch for io routines
I am currently trying to improve on the front-backend communication
routines; and noticed that lots of code are duplicated for libpq and
the backend. This is a first patch that tries to share code between
the two, more to follow.
mjl
Subject: [HACKERS] password authentication
This patch adds support for plaintext password authentication. To use
it, you add a line like
host all 0.0.0.0 0.0.0.0 password pg_pwd.conf
to your pg_hba.conf, where 'pg_pwd.conf' is the name of a file containing
the usernames and password hashes in the format of the first two fields
of a Unix /etc/passwd file. (Of course, you can use a specific database
name or IP instead.)
Then, to connect with a password through libpq, you use the PQconnectdb()
function, specifying the "password=" tag in the connect string and also
adding the tag "authtype=password".
I also added a command-line switch '-u' to psql that tells it to prompt
for a username and password and use password authentication.
#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
At least the first two should be fixed before the final release of 6.0.
1) There is a mismatch between the type declared in the catalog for
the input/output attributes of pg_type and the actual type of
values stored in the table. The type of typinput, typoutput,
typsend and typreceive are declared oid (26) while the values are
regproc (24). The error was there also in previous versions but
nobody noticed it until an Assert has been added in ExecEvalVar.
The effect is that it is now impossible to replace the typoutput
of existing data types with new procs.
2) The identd hba fails after the first time because the data read
from the identd socket is not zero-terminated and strlen reports
an incorrect length if the stack contains garbage, which usually
happens after the first connection has been made.
3) The new initdb wants to create itself the data directory. This
implies that the parent directory must be writable by postgres and
this may not always be desirable. A better solution would be to
allow the directory to be created by root and then filled by initdb.
It would also nice to have some reasonable default for PGLIB and
PGDATA like the previous version did. This applies also to the
postmaster executable.
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
these routines try to use the old pointer casting stuff to get
the connection id, second the notification hash table should
be part of the cliendData. Otherwise, one interpreter might
eat up the notifies for another one.
Please apply the patch below to the current 6.0 tree.
Submitted by: wieck@sapserv.debis.de
gmake of the code without interruption.
There's also some tidy-up of the MAXPATHLEN stuff based on the assumption that
all supported platforms have MAXPATHLEN defined in <sys/param.h>.
(The only unknowns for the above are AIX and IRIX5.)
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)
In particular, no more compiled-in default for PGDATA or LIBDIR. Commands
that need them need either invocation options or environment variables.
PGPORT default is hardcoded as 5432, but overrideable with options or
environment variables.
following is the patch to libpq's large object interface that
removes the requirement to include fmgr.h into fe-lobj.c.
The large object interface now ask's the backend to tell the
OID's of all the required functions in pg_proc.
From: wieck@sapserv.debis.de (Jan Wieck)
other platforms). If I do the standard make + make install the shared library
is not linked with the the libpq library and when I try to load it in the
standard Tcl or Tk shell I get a lot of unresolved symbols. The bug doesn't
affect pgtclsh because it is linked also with libpq. The problem exists only
when using the dynamic load feature of Tcl7.5.
From: Massimo Dal Zotto <dz@cs.unitn.it>
Adds:
-lAttributes
Returns another format of the results attribute list. Per
attribute a sublist of {{attname} atttype attlen} is
returned and an empty string if no attributes where
received.
-numAttrs
Returns the number of attributes in the result.
function so I am going to assume that it is such a good idea that no
one sees any point in discussing it. :-) I have made two changes -
I have merged this into pgtclCmds.c and I have taken out any code for
updating tuples after the loop body runs. See comments for discussion
of this.
I have also fixed up the error checking stuff so that break, continue
and syntax errors have the expected result.
Submitted by: D'Arcy Cain
way one creates a database system. Parts that were in "make install"
are not either in "make all" or initdb. Nothing goes in the PGDATA
directory besides user data. Creating multiple database systems is
easier.
In addition to applying the patch, it is necessary to move the file
libpq/pg_hba to backend/libpq/pg_hba.sample.
Submitted by: Bryan Henderson <bryanh@giraffe.netgate.net>
attributes as tcl arrays. The previous code had problems with some chars
used as delimiter by Tcl. The new code should be more robust.
By: Massimo Dal Zotto <dz@cs.unitn.it>
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>
|record, by a small patch to libpq++? At least until the
|feature that will allow dumped oid's to be re-loaded into
|a database becomes available, I need access to the oids
|of newly created records... To this end, I have written a
|three-line wrapper for the PQoidStatus function in libpq and
|named this wrapper OidStatus() (I'd appreciate suggestions for
|a name that would better fit into the general naming scheme).
|
|Regards,
|
|Ernst
|
When you connect to a database with PQsetdb, as with psql, depending on
how your uninitialized variables are set, you can get a failure with a
"There is no connection to the backend" message.
The fix is to move a call to PQexec() from inside connectDB() to
PQsetdb() after connectDB() returns to PQsetdb(). That way a connection
doesn't have to be already established in order to establish it!
From: bryanh@giraffe.netgate.net (Bryan Henderson)
|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>
Kerberos is being used (attempt to free static memory).
The error was caused by a confusing doublespeak of fe_getauthname():
Returns a pointer to static memory, if you authenticate via Kerberos,
a pointer to dynamic memory otherwise.
Submitted by: Erich Stamberger <eberger@gewi.kfunigraz.ac.at>
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>