Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Stephen Frost wrote: >> I'm going to have to vote 'silly' on this one. > It's a matter of being consistent. If we think such a facility shouldn't > be provided on security grounds, then we shouldn't allow it via a > backdoor, ISTM. Well, the problem with this approach is that libpq has no real means of knowing whether a string it's been passed was exposed on the command line or not. dbName might be secure, and for that matter the conninfo string passed to PQconnectdb might be insecure. Should we put in arbitrary restrictions on the basis of hypotheses about where these different arguments came from? It's also worth noting that we haven't removed the PGPASSWORD environment variable, even though that's demonstrably insecure on some platforms. I'm actually inclined to vote with Stephen that this is a silly change. I just put up the patch to show the best way of doing it if we're gonna do it ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Stephen Frost wrote: * Tom Lane ([EMAIL PROTECTED]) wrote: Anybody think this is good, bad, or silly? Does the issue need explicit documentation, and if so where and how? I'm going to have to vote 'silly' on this one. While I agree that in general we should discourage, and not provide explicit command-line options for, passing a password on the command-line, I don't feel that it makes sense to explicitly complicate things to prevent it. It's a matter of being consistent. If we think such a facility shouldn't be provided on security grounds, then we shouldn't allow it via a backdoor, ISTM. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: Tom Lane wrote: As of PG 8.3, libpq allows a conninfo string to be passed in via the dbName parameter of PQsetdbLogin. I didn't even know we could do that. I always use the shell variable option instead. Does anyone actually use the facility? Well, not yet, because it's new in 8.3 ... Yeah, let's not do that. Like you said, "While we cannot absolutely prevent client apps from doing stupid things, it seems like it might be a good idea to prevent passwords from being passed in through dbName. " To me... this is something that if we allow, people will use it, and we will end up removing it, realizing it is a bad idea. There are plenty of other ways to pass the password in a more sane way. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
* Tom Lane ([EMAIL PROTECTED]) wrote: > Anybody think this is good, bad, or silly? Does the issue need > explicit documentation, and if so where and how? I'm going to have to vote 'silly' on this one. While I agree that in general we should discourage, and not provide explicit command-line options for, passing a password on the command-line, I don't feel that it makes sense to explicitly complicate things to prevent it. Just my 2c, Thanks, Stephen signature.asc Description: Digital signature
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> As of PG 8.3, libpq allows a conninfo string to be passed in via the >> dbName parameter of PQsetdbLogin. > I didn't even know we could do that. I always use the shell variable > option instead. Does anyone actually use the facility? Well, not yet, because it's new in 8.3 ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Proposed patch to disallow password=foo in database name parameter
Tom Lane wrote: As of PG 8.3, libpq allows a conninfo string to be passed in via the dbName parameter of PQsetdbLogin. This is to allow access to conninfo facilities in old programs that are still using PQsetdbLogin (including most of our own standard clients ... ahem). For instance psql "service = foo" Andrew Dunstan pointed out a possible security hole in this: it will allow people to do psql "dbname = mydb password = mypassword" which would leave their password exposed on the program's command line. While we cannot absolutely prevent client apps from doing stupid things, it seems like it might be a good idea to prevent passwords from being passed in through dbName. The attached patch (which depends on some pretty-recent changes in CVS HEAD) accomplishes this. Anybody think this is good, bad, or silly? Does the issue need I didn't even know we could do that. I always use the shell variable option instead. Does anyone actually use the facility? explicit documentation, and if so where and how? I think it should just throw a syntax error, this isn't covered as an ability in the man page. I doubt anyone is honestly using this that isn't smart enough to just figure out it isn't supported. Joshua D. Drake ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] Proposed patch to disallow password=foo in database name parameter
As of PG 8.3, libpq allows a conninfo string to be passed in via the
dbName parameter of PQsetdbLogin. This is to allow access to conninfo
facilities in old programs that are still using PQsetdbLogin (including
most of our own standard clients ... ahem). For instance
psql "service = foo"
Andrew Dunstan pointed out a possible security hole in this: it will
allow people to do
psql "dbname = mydb password = mypassword"
which would leave their password exposed on the program's command line.
While we cannot absolutely prevent client apps from doing stupid things,
it seems like it might be a good idea to prevent passwords from being
passed in through dbName. The attached patch (which depends on some
pretty-recent changes in CVS HEAD) accomplishes this.
Anybody think this is good, bad, or silly? Does the issue need
explicit documentation, and if so where and how?
regards, tom lane
Index: fe-connect.c
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.354
diff -c -r1.354 fe-connect.c
*** fe-connect.c9 Dec 2007 19:01:40 - 1.354
--- fe-connect.c11 Dec 2007 02:46:22 -
***
*** 599,604
--- 599,618
{
if (!connectOptions1(conn, dbName))
return conn;
+
+ /*
+* We disallow supplying a password through dbName, because a
large
+* number of applications allow dbName to be set from a
command-line
+* parameter, and putting a password on your command line is a
horrid
+* idea from a security point of view.
+*/
+ if (conn->pgpass_from_client)
+ {
+ conn->status = CONNECTION_BAD;
+ printfPQExpBuffer(&conn->errorMessage,
+
libpq_gettext("password must not be set within database name parameter\n"));
+ return conn;
+ }
}
else
{
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] pgbench - startup delay
Greg Smith <[EMAIL PROTECTED]> writes: > That clarifies the situation well enough for me. I think this is a two > part problem then. It's not necessarily obvious that pgbench will use > PGOPTIONS. In addition to that, the current documentation is less clear > than it could be on the subject of what you can usefully put into > PGOPTIONS. That's two small documentation patches I should be able to > handle. BTW, PGOPTIONS is actually just the environment-variable fallback for the pgoptions argument to PQsetdbLogin() or the options=whatever component of the conninfo string for PQconnectdb() --- it's the same sort of animal as PGHOST or PGPORT. So those provide alternate paths for getting at the same functionality, and any documentation patch should be clear about this. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] pgbench - startup delay
On Mon, 10 Dec 2007, Neil Conway wrote: Perhaps one of the slightly unfortunate consequences of the postmaster => postgres merge is that there is less of a clear distinction between "postmaster options" and "postgres" options... I'd already read all of the documentation that you and Tom suggested just before I sent my previous message, and I didn't find this subject clear at all. On Mon, 10 Dec 2007, Tom Lane wrote: It's not pgbench that is paying attention to this, it's libpq. Right, but I wouldn't expect a typical pgbench user to know that. Anything you'd be allowed to SET can be set from PGOPTIONS (-c or --var syntax...the restrictions are the same as for the underlying variable. That clarifies the situation well enough for me. I think this is a two part problem then. It's not necessarily obvious that pgbench will use PGOPTIONS. In addition to that, the current documentation is less clear than it could be on the subject of what you can usefully put into PGOPTIONS. That's two small documentation patches I should be able to handle. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] pgbench - startup delay
Greg Smith <[EMAIL PROTECTED]> writes: > I once wrote a similar patch to the one Dave submitted here and feel like > it's worth committing at least a documentation patch to show how to deal > with this. It's not obvious that pgbench pays attention to the > environment variables at all, and it's even less obvious that you can pass > what look like server options in there. It's not pgbench that is paying attention to this, it's libpq. This is at least referred to in the libpq and server documentation, eg the tenth paragraph here: http://developer.postgresql.org/pgdocs/postgres/config-setting.html It might be worth more emphasis, not sure. It doesn't come up all that often. > I just poked around the > documentation a bit and I didn't find anything that cleared up which > options you can pass from a client; in addition to -W, I can imagine > pgbench users might also want to use -S (sort memory) or -f (forbid > scan/join types). If I can get someone to clarify what is supported there > I can put together a pgbench doc patch that addresses this topic. Anything you'd be allowed to SET can be set from PGOPTIONS (-c or --var syntax). As for the special-purpose postgres command-line switches, I believe they are all equivalent to one or another GUC variable: http://developer.postgresql.org/pgdocs/postgres/runtime-config-short.html so the restrictions are the same as for the underlying variable. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] pgbench - startup delay
On Mon, 2007-12-10 at 19:12 -0500, Greg Smith wrote: > I just poked around the > documentation a bit and I didn't find anything that cleared up which > options you can pass from a client http://www.postgresql.org/docs/8.2/static/libpq-envars.html Which says only "PGOPTIONS sets additional run-time options for the PostgreSQL server." This could probably be elaborated upon -- for the list of options accepted, see PostgresMain() in tcop/postgres.c Perhaps one of the slightly unfortunate consequences of the postmaster => postgres merge is that there is less of a clear distinction between "postmaster options" and "postgres" options... -Neil ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] pgbench - startup delay
On Mon, 10 Dec 2007, Tom Lane wrote: I concur with Alvaro that this case seems adequately covered by PGOPTIONS="-W n" pgbench ... I started to disagree with this, but ultimately realized anyone who is running pgbench for long enough to get useful results shouldn't have their TPS impacted much at all by a few overhead seconds tacked onto the server startup. I once wrote a similar patch to the one Dave submitted here and feel like it's worth committing at least a documentation patch to show how to deal with this. It's not obvious that pgbench pays attention to the environment variables at all, and it's even less obvious that you can pass what look like server options in there. I just poked around the documentation a bit and I didn't find anything that cleared up which options you can pass from a client; in addition to -W, I can imagine pgbench users might also want to use -S (sort memory) or -f (forbid scan/join types). If I can get someone to clarify what is supported there I can put together a pgbench doc patch that addresses this topic. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] pgbench - startup delay
Dave Page <[EMAIL PROTECTED]> writes: > Alvaro Herrera wrote: >> I think you could get the same effect by putting the -W in PGOPTIONS (in >> pgbench's environment). > That's a good point. It does have the downside that it will affect the > pgbench results - though that wouldn't actually be an issue for what I > was doing. Well, if you're attaching a profiler or debugger to a backend, you're hardly gonna get unadulterated TPS readings from pgbench anyway. I concur with Alvaro that this case seems adequately covered by PGOPTIONS="-W n" pgbench ... which is what I've always used in similar situations... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgbench - startup delay
Alvaro Herrera wrote: > Dave Page wrote: > >> I'm aware of postgres -W, but wanted something that wouldn't get in the >> way of other connections and would only affect my pgbench tests. > > I think you could get the same effect by putting the -W in PGOPTIONS (in > pgbench's environment). > That's a good point. It does have the downside that it will affect the pgbench results - though that wouldn't actually be an issue for what I was doing. /D ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] pgbench - startup delay
Dave Page wrote: > I'm aware of postgres -W, but wanted something that wouldn't get in the > way of other connections and would only affect my pgbench tests. I think you could get the same effect by putting the -W in PGOPTIONS (in pgbench's environment). -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC "No renuncies a nada. No te aferres a nada." ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] pgbench - startup delay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 10 Dec 2007 19:58:21 + Dave Page <[EMAIL PROTECTED]> wrote: > Neil Conway wrote: > > On Mon, 2007-12-10 at 19:27 +, Dave Page wrote: > >> Whilst doing some profiling of the server I found it useful to add > >> an option to pgbench to introduce a delay between client > >> connection setup and the start of the benchmark itself to allow me > >> time to attach the profiler to one of the backends. > > > > "postgres -W n" already does this. It is more flexible to put this > > functionality in the backend that in individual client apps anyway. > > I'm aware of postgres -W, but wanted something that wouldn't get in > the way of other connections and would only affect my pgbench tests. > > If the patch is of no interest, please just ignore it. I just posted > it for anyone that may find it useful - I'm not pushing to have it > committed. I see use for it. Especially in a development environment where you may have various things going on that you have no control over. It is rude to send out a broadcast that says, "Yo... I need to restart postgresql, please stop all productive tasks on your end because I am more important." +1 on enabling client side behavior. Joshua D. Drake - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHXZtEATb/zqfZUUQRAiWoAJ0ULTUziKVDkuqXmUyvgYCSA0f+hwCgl/ay SZjqJZIaGLxTBpbuKEzBc4Y= =Ku+C -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] pgbench - startup delay
Neil Conway wrote: > On Mon, 2007-12-10 at 19:27 +, Dave Page wrote: >> Whilst doing some profiling of the server I found it useful to add an >> option to pgbench to introduce a delay between client connection setup >> and the start of the benchmark itself to allow me time to attach the >> profiler to one of the backends. > > "postgres -W n" already does this. It is more flexible to put this > functionality in the backend that in individual client apps anyway. I'm aware of postgres -W, but wanted something that wouldn't get in the way of other connections and would only affect my pgbench tests. If the patch is of no interest, please just ignore it. I just posted it for anyone that may find it useful - I'm not pushing to have it committed. Regards, Dave. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] pgbench - startup delay
On Mon, 2007-12-10 at 19:27 +, Dave Page wrote: > Whilst doing some profiling of the server I found it useful to add an > option to pgbench to introduce a delay between client connection setup > and the start of the benchmark itself to allow me time to attach the > profiler to one of the backends. "postgres -W n" already does this. It is more flexible to put this functionality in the backend that in individual client apps anyway. -Neil ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] pgbench - startup delay
Dave Page wrote: > Whilst doing some profiling of the server I found it useful to add an > option to pgbench to introduce a delay between client connection setup > and the start of the benchmark itself to allow me time to attach the > profiler to one of the backends. Hmm, the backend already has a delay, see -W. -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4" "Executive Executive Summary: The [Windows] Vista Content Protection specification could very well constitute the longest suicide note in history." Peter Guttman, http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] pgbench - startup delay
Whilst doing some profiling of the server I found it useful to add an
option to pgbench to introduce a delay between client connection setup
and the start of the benchmark itself to allow me time to attach the
profiler to one of the backends.
Attached is the patch in case anyone finds a use for it, or if it's
deemed to be generally useful enough for inclusion in 8.4.
Regards, Dave.
Index: doc/src/sgml/pgbench.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/pgbench.sgml,v
retrieving revision 1.4
diff -c -r1.4 pgbench.sgml
*** doc/src/sgml/pgbench.sgml 10 Dec 2007 05:32:51 - 1.4
--- doc/src/sgml/pgbench.sgml 10 Dec 2007 19:05:13 -
***
*** 250,255
--- 250,264
+ -w startup_delay
+
+Pause for the specified number of seconds after creating the
+client connections. This is useful to allow time to connect
+a debugger or profiler to a backend server process before the
+benchmark is run.
+
+
+
-d
Print debugging output.
Index: contrib/pgbench/pgbench.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pgbench/pgbench.c,v
retrieving revision 1.74
diff -c -r1.74 pgbench.c
*** contrib/pgbench/pgbench.c 15 Nov 2007 21:14:31 - 1.74
--- contrib/pgbench/pgbench.c 10 Dec 2007 18:58:55 -
***
*** 188,194
static void
usage(void)
{
! fprintf(stderr, "usage: pgbench [-h hostname][-p port][-c nclients][-t ntransactions][-s scaling_factor][-D varname=value][-n][-C][-v][-S][-N][-f filename][-l][-U login][-P password][-d][dbname]\n");
fprintf(stderr, "(initialize mode): pgbench -i [-h hostname][-p port][-s scaling_factor] [-F fillfactor] [-U login][-P password][-d][dbname]\n");
}
--- 188,194
static void
usage(void)
{
! fprintf(stderr, "usage: pgbench [-h hostname][-p port][-c nclients][-t ntransactions][-s scaling_factor][-D varname=value][-n][-C][-v][-S][-N][-f filename][-l][-U login][-P password][-w startup_delay][-d][dbname]\n");
fprintf(stderr, "(initialize mode): pgbench -i [-h hostname][-p port][-s scaling_factor] [-F fillfactor] [-U login][-P password][-d][dbname]\n");
}
***
*** 1163,1169
printResults(
int ttype, CState * state,
struct timeval * tv1, struct timeval * tv2,
! struct timeval * tv3)
{
double t1,
t2;
--- 1163,1169
printResults(
int ttype, CState * state,
struct timeval * tv1, struct timeval * tv2,
! struct timeval * tv3, int startup_delay)
{
double t1,
t2;
***
*** 1174,1183
for (i = 0; i < nclients; i++)
normal_xacts += state[i].cnt;
! t1 = (tv3->tv_sec - tv1->tv_sec) * 100.0 + (tv3->tv_usec - tv1->tv_usec);
t1 = normal_xacts * 100.0 / t1;
! t2 = (tv3->tv_sec - tv2->tv_sec) * 100.0 + (tv3->tv_usec - tv2->tv_usec);
t2 = normal_xacts * 100.0 / t2;
if (ttype == 0)
--- 1174,1183
for (i = 0; i < nclients; i++)
normal_xacts += state[i].cnt;
! t1 = (tv3->tv_sec - (tv1->tv_sec + startup_delay)) * 100.0 + (tv3->tv_usec - tv1->tv_usec);
t1 = normal_xacts * 100.0 / t1;
! t2 = (tv3->tv_sec - (tv2->tv_sec + startup_delay)) * 100.0 + (tv3->tv_usec - tv2->tv_usec);
t2 = normal_xacts * 100.0 / t2;
if (ttype == 0)
***
*** 1217,1222
--- 1217,1224
struct timeval tv2; /* after establishing all connections to the
* backend */
struct timeval tv3; /* end time */
+
+ int startup_delay = 0; /* Post-connect delay */
int i;
***
*** 1258,1264
memset(state, 0, sizeof(*state));
! while ((c = getopt(argc, argv, "ih:nvp:dc:t:s:U:P:CNSlf:D:F:")) != -1)
{
switch (c)
{
--- 1260,1266
memset(state, 0, sizeof(*state));
! while ((c = getopt(argc, argv, "ih:nvp:dc:t:s:U:P:CNSlf:D:F:w:")) != -1)
{
switch (c)
{
***
*** 1371,1376
--- 1373,1386
exit(1);
}
break;
+ case 'w':
+ startup_delay = atoi(optarg);
+if (startup_delay < 0)
+ {
+ fprintf(stderr, "invalid startup_delay: %d\n", startup_delay);
+ exit(1);
+ }
+ break;
default:
usage();
exit(1);
***
*** 1553,1558
--- 1563,1580
/* time after connections set up */
gettimeofday(&tv2, NULL);
+ if (startup_delay)
+ {
+ fprintf(stderr, "pausing for %d seconds...", startup_delay);
+ #ifndef WIN32
+ sleep(startup_delay);
+ #else
+ Sleep(startup_delay * 1000);
+ #endif
+ fprintf(stderr, "end.\n");
+
+ }
+
/* process bultin SQL scripts */
switch (ttype)
{
***
*** 1600,1606
disconnect_all(state);
/* get end time */
gettimeofday(&tv3, NULL);
! printResults(ttype, state, &tv
Re: [PATCHES] plpgsql, forc statement
This has been saved for the 8.4 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Pavel Stehule wrote: > Hello > > per proposal http://archives.postgresql.org/pgsql-hackers/2007-11/msg01012.php > > This patch allows iteration over cursor, so longer SELECTs can be > written outside cycle. Clean some related redundant code too. > > Regards > Pavel Stehule [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Re: [HACKERS] Problem with ControlFileData structure being ABI depe ndent
Dave Page wrote:
> Tom Lane wrote:
>> Dave Page <[EMAIL PROTECTED]> writes:
>>> Gregory Stark wrote:
An alternative is leaving it in the project file but putting
something like
this in c.h:
>>
>> Put it in win32.h, please. c.h shouldn't get cluttered with
>> platform-specific kluges when there's no need for it.
>>
>> Is there a good reason not to just #define _USE_32BIT_TIME_T in win32.h?
>
> Yeah, the fact that addons may then end up partially compiled with and
> partially without it being defined. It we just have it error as Greg
> suggested, then it will force the authors to define it themselves, and
> if they get that wrong it's their fault not ours.
Patch attached.
/D
Index: src/include/port/win32.h
===
RCS file: /projects/cvsroot/pgsql/src/include/port/win32.h,v
retrieving revision 1.81
diff -c -r1.81 win32.h
*** src/include/port/win32.h 24 Nov 2007 01:55:26 - 1.81
--- src/include/port/win32.h 10 Dec 2007 09:42:44 -
***
*** 45,50
--- 45,61
#define USES_WINSOCK
+ /*
+ * Ensure that anyone building an extension is using a 32 bit time_t.
+ * On Mingw/Msys, that should always be the case, but MSVC++ defaults
+ * to 64 bits. We set that for our own build in the project files
+ */
+ #ifdef WIN32
+ #ifndef _USE_32BIT_TIME_T
+ #error "Postgres uses 32 bit time_t - add #define _USE_32BIT_TIME_T on Windows
+ #endif
+ #endif
+
/* defines for dynamic linking on Win32 platform */
#if defined(WIN32) || defined(__CYGWIN__)
Index: src/tools/msvc/Project.pm
===
RCS file: /projects/cvsroot/pgsql/src/tools/msvc/Project.pm,v
retrieving revision 1.14
diff -c -r1.14 Project.pm
*** src/tools/msvc/Project.pm 21 Aug 2007 15:10:41 - 1.14
--- src/tools/msvc/Project.pm 7 Dec 2007 11:14:29 -
***
*** 489,495
ConfigurationType="$cfgtype" UseOfMFC="0" ATLMinimizesCRunTimeLibraryUsage="FALSE" CharacterSet="2" WholeProgramOptimization="$p->{wholeopt}">
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
