pgsql/src/interfaces/libpq fe-auth.c fe-connec ...

From: momjian(at)postgresql(dot)org (Bruce Momjian - CVS)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql/src/interfaces/libpq fe-auth.c fe-connec ...
Date: 2002-07-20 05:43:31
Message-ID: 20020720054331.942A0475DB7@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

CVSROOT: /cvsroot
Module name: pgsql
Changes by: momjian(at)postgresql(dot)org 02/07/20 01:43:31

Modified files:
src/interfaces/libpq: fe-auth.c fe-connect.c fe-secure.c
libpq-int.h libpqdll.c win32.c win32.h
win32.mak

Log message:
Hello, i noticed that win32 native stopped working/compiling after the SSL merge
.
So i took the opportunity to fix some stuff:

1. Made the thing compile (typos & needed definitions) with the new pqsecure_* s
tuff, and added fe-secure.c to the win32.mak makefile.
2. Fixed some MULTIBYTE compile errors (when building without MB support).
3. Made it do that you can build with debug info: "nmake -f win32.mak DEBUG=1".
4. Misc small compiler speedup changes.

The resulting .dll has been tested in production, and everything seems ok.
I CC:ed -hackers because i'm not sure about two things:

1. In libpq-int.h I typedef ssize_t as an int because Visual C (v6.0)
doesn't de fine ssize_t. Is that ok, or is there any standard about what
type should be use d for ssize_t?

2. To keep the .dll api consistent regarding MULTIBYTE I just return -1
in fe-connect.c:PQsetClientEncoding() instead of taking away the whole
function. I wonder if i should do any compares with the
conn->client_encoding and return 0 if not hing would have changed (if so
how do i check that?).

Regards

Magnus Naeslund

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian - CVS 2002-07-20 05:49:28 pgsql/src backend/commands/explain.c backend/e ...
Previous Message Bruce Momjian - CVS 2002-07-20 05:39:46 pgsql/src/test/regress expected/without_oid.ou ...