Subject: [PATCHES] 970417: some large object patches
Two patches here, made against 970417. Both have to do with large
objects:
1. lobjfuncs was not initialized in PQconnectdb. This causes
failure later if large objects are used. (Someone already
caught this error in PQsetdb.)
2. Postgres functions lo_import and lo_export sometimes
produce garbage for the file names because the filename
strings aren't always terminated by \0. (VARDATA isn't
necessarily null terminated.)
FreeBSD
The Makefile(s) have all been cleaned up such that there is a single
LDFLAGS vs LD_ADD or LDADD or LDFLAGS or LDFLAGS_BE. The Makefile(s)
should be alot more straightforward then they were before...and
consistent
The first fixes a warning from gcc about the assignment within the condition.
The extra set of parens should not make a difference, but with -Werror, they
are necessary.
The second fixes an "ln -s" invocation that assumes the current directory is
implicitly the target if not specified. Not true in all cases, and again, it
should not make a difference except to those implementation that it does.
From: "Michael P. Snyder" <msnyder@hawkeye.huntersmoon.com>
nicer. Also, I grabbed my copy of the Informix manual, and
added a couple of variables that make sense (formats for
money, time, a language setting, a timezone).
- New functions SetPGVariable() and GetPGVariable() in tcop/*.
These don't actually do anything for the moment, but should
be enough to implement the SET var_name TO var_val in the
parser?
SetPGVariable() expects just two strings, the var_name and
the var_value from above, and is expected to do the right thing.
Returns TRUE if everything okay.
From: "Martin J. Laubach" <mjl@wwx.vip.at>
of common routines in pqcomprim.c (pq communication primitives).
Not all adapted to it yet, but it's a start.
- Rewritten some of those routines, to write/read bigger chunks of
data, precomputing stuff in buffers instead of sending out byte
by byte.
- As a consequence, I need to know the endianness of the machine.
Currently I rely on getting it from machine/endian.h, but this
may not be available everywhere? (Who the hell thought it was
a good idea to pass integers to the backend the other way around
than the normal network byte order? *argl*)
- Libpq looks in the environment for magic variables, and upon
establishing a connection to the backend, sends it queries
of the form "SET var_name TO 'var_value'". This needs a change
in the backend parser (Mr. Parser, are you there? :)
- Currently it looks for two Env-Vars, namely PG_DATEFORMAT
and PG_FLOATFORMAT. What else makes sense? PG_TIMEFORMAT?
PG_TIMEZONE?
From: "Martin J. Laubach" <mjl@wwx.vip.at>
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
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
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)
