Go to file
Bruce Momjian bd0a767eab Here is a patch to make the current snapshot compile on Win32 (native, libpq
and psql) again. Changes are:
1) psql requires the includes of "io.h" and "fcntl.h" in command.c in order
to make a call to open() work (io.h for _open(), fcntl.h for the O_xxx)
2) PG_VERSION is no longer defined in version.h[.in], but in configure.in.
Since we don't do configure on native win32, we need to put it in
config.h.win32 :-(
3) Added define of SYSCONFDIR to config.h.win32 - libpq won't compile
without it. This functionality is *NOT* tested - it's just defined as "" for
now. May work, may not.
4) DEF_PGPORT renamed to DEF_PGPORT_STR

I have done the "basic tests" on it - it connects to a database, and I can
run queries. Haven't tested any of the fancier functions (yet).

However, I stepped on a much bigger problem when fixing psql to work. It no
longer works when linked against the .DLL version of libpq (which the
Makefile does for it). I have left it linked against this version anyway,
pending the comments I get on this mail :-)
The problem is that there are strings being allocated from libpq.dll using
PQExpBuffers (for example, initPQExpBuffer() on line 92 of input.c). These
are being allocated using the malloc function used by libpq.dll. This
function *may* be different from the malloc function used by psql.exe - only
the resulting pointer must be valid. And with the default linking methods,
it *WILL* be different. Later, psql.exe tries to free() this string, at
which point it crashes because the free() function can't find the allocated
block (it's on the allocated blocks list used by the runtime lib of
libpq.dll).

Shouldn't the right thing to do be to have psql call termPQExpBuffer() on
the data instead? As it is now, gets_fromFile() will just return the pointer
received from the PQExpBuffer.data (this may well be present at several
places - this is the one I was bitten by so far). Isn't that kind of
"accessing the internals of the PQExpBuffer structure" wrong? Instead,
perhaps it shuold make a copy of the string, adn then termPQExpBuffer() it?
In that case, the string will have been allocated from within the same
library as the free() is called.

I can get it to work just fine by doing this - changing from (around line
100 of input.c):
and the same a bit further down in the same function.

But, as I said above, this may be at more places in the code? Perhaps
someone more familiar to it could comment on that?


What do you think shuld be done about this? Personally, I go by the "If you
allocate a piece of memory using an interface, use the same interface to
free it", but the question is how to make it work :-)


Also, AFAIK this only affects psql.exe, so the changes made to the libpq
this patch are required no matter how the other issue is handled.

Regards,
 Magnus
2001-01-24 03:42:38 +00:00
ChangeLogs check one last time for any erros ... 2001-01-13 03:17:05 +00:00
config Remove rangechecks on errno; just call strerror unconditionally. This 2001-01-22 23:28:52 +00:00
contrib Update 2001-01-24 03:40:33 +00:00
doc Update 2001-01-24 03:40:33 +00:00
src Here is a patch to make the current snapshot compile on Win32 (native, libpq 2001-01-24 03:42:38 +00:00
COPYRIGHT Update copyright file. 2000-01-29 08:53:10 +00:00
GNUmakefile.in Use more portable syntax for 'find'. 2001-01-06 21:24:01 +00:00
HISTORY check one last time for any erros ... 2001-01-13 03:17:05 +00:00
INSTALL Adjust file names. 2001-01-15 21:17:27 +00:00
Makefile Fix unportable use of '!' in shell commands. 2000-12-30 00:24:09 +00:00
README check one last time for any erros ... 2001-01-13 03:17:05 +00:00
aclocal.m4 Add some configure checks for DocBook and related tools. With a somewhat 2000-11-05 21:04:07 +00:00
build.xml Thu Jan 18 12:24:00 GMT 2001 peter@retep.org.uk 2001-01-18 14:50:15 +00:00
configure Remove rangechecks on errno; just call strerror unconditionally. This 2001-01-22 23:28:52 +00:00
configure.in Remove rangechecks on errno; just call strerror unconditionally. This 2001-01-22 23:28:52 +00:00
register.txt Updates for 7.1 branding. 2000-12-18 16:30:07 +00:00

README

PostgreSQL Data Base Management System (formerly known as Postgres, then
as Postgres95).
  
This directory contains the development version of 7.1 of the
PostgreSQL database server.  The server is not ANSI SQL compliant, but
it gets closer with every release.  After you unzip and untar the
distribution file, look at file INSTALL for the installation notes and
file HISTORY for the changes.

The latest version of this software may be obtained at
ftp://ftp.postgresql.org/pub/.  For more information look at our WWW
home page located at http://www.postgreSQL.org/.

PostgreSQL is not public domain software.  It is copyrighted by the
University of California but may be used according to the licensing
terms of the the copyright below:

------------------------------------------------------------------------

POSTGRES95 Data Base Management System (formerly known as Postgres, then
as Postgres95).

Copyright (c) 1994-7 Regents of the University of California

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written agreement
is hereby granted, provided that the above copyright notice and this
paragraph and the following two paragraphs appear in all copies.

IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS
DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE.  THE SOFTWARE PROVIDED HEREUNDER IS
ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO
PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.