- 19 6月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
Andreas Pflug
-
- 29 4月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 08 3月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
feature for Win32 and bcc.
-
- 28 2月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
consistency. Backpatch only bcc32.mak to 8.0.X.
-
- 22 2月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
Backpatch to 8.0.X which doesn't work right now.
-
- 27 1月, 2005 1 次提交
-
-
由 Tom Lane 提交于
APPDATA directory on Windows. Magnus Hagander
-
- 10 1月, 2005 1 次提交
-
-
由 Tom Lane 提交于
-
- 13 11月, 2004 1 次提交
-
-
由 Bruce Momjian 提交于
lacking pqsignal which is now required. This was found and fixed for VC++ by Shachar Shemesh, I simply duplicated the fix for the Borland makefile (untested, as I don't have that compiler). Dave Page
-
- 17 10月, 2004 1 次提交
-
-
由 Tom Lane 提交于
just stick a list-link into struct PGnotify instead. Result is a smaller faster and more robust library (mainly because we reduce the number of malloc's and free's involved in notify processing), plus less pollution of application link-symbol namespace.
-
- 02 9月, 2004 1 次提交
-
-
由 Bruce Momjian 提交于
will succeed.
-
- 19 6月, 2004 1 次提交
-
-
由 Bruce Momjian 提交于
Andreas Pflug
-
- 04 6月, 2004 1 次提交
-
-
由 Bruce Momjian 提交于
ENABLE_THREAD_SAFETY is supported by the makefile (but not by the sources, which need some rework) Andreas Pflug
-
- 03 6月, 2004 1 次提交
-
-
由 Bruce Momjian 提交于
Andreas Pflug
-
- 05 4月, 2004 1 次提交
-
-
由 Bruce Momjian 提交于
be built under VC++. Moves a pgstat win32 #def to port.h Claudio Natoli
-
- 09 3月, 2004 1 次提交
-
-
由 Bruce Momjian 提交于
Currently, src/interfaces/libpq/win32.mak builds a statically-linked library "libpq.lib", a debug dll "libpq.dll", import library for the debug dll "libpqdll.lib", a release dll "libpq.dll", import library for the release dll "libpqdll.lib". To avoid naming clashes, I would make the debug dll and import libraries "libpqd.dll" and "libpqddll.lib". Basically, the debug build uses the cl flags: "/MDd /D _DEBUG", and the release build uses the cl flags "/MD /D NDEBUG". Usually the debug build has a "D" suffix on the file name, so for example: libpqd.dll libpq, debug build libpqd.lib libpq, debug build, import library libpq.dll libpq, release build libpq.lib libpq, release build, import library David Turner
-
- 30 11月, 2003 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 05 9月, 2003 1 次提交
-
-
由 Bruce Momjian 提交于
platform. Andreas Pflug
-
- 12 6月, 2003 3 次提交
-
-
由 Bruce Momjian 提交于
Compiles on BCC 5.5 and VC++ 6.0 (with warnings). Karl Waclawek
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
Also quickly added mention that it may be a qualified schema name. Rod Taylor
-
- 04 9月, 2002 1 次提交
-
-
由 Peter Eisentraut 提交于
referring to "multibyte" where it really means character encoding.
-
- 20 7月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
. 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
-
- 24 4月, 2002 1 次提交
-
-
由 Bruce Momjian 提交于
work on all win9x machines, so i made it go thru a l ookup table instead, using the DLL as last resort. I also moved this out of the fe-misc.c file because of the size of the lookup ta ble. Who knows, we might add more other win32 specific code there in the future. I also fixed a small typo in the pg_config.h.win32 that made the compiler compla in about the gnu snprintf declaration. I tried to make this patch with psql coding style. I've successfully tested this on win2k and win98 and it works fine (i.e. the mes sage shows on win98 too, it didn't with the old implementation). Magnus Naeslund
-
- 22 11月, 2001 1 次提交
-
-
由 Hiroshi Inoue 提交于
Multibyte mode.
-
- 25 8月, 2001 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 04 8月, 2001 1 次提交
-
-
由 Tom Lane 提交于
backend files that it shouldn't anymore, causing compile failures. Per report from Darko Prenosil.
-
- 28 1月, 2001 1 次提交
-
-
由 Bruce Momjian 提交于
and two 'win32.mak'. Addresses the following: 1) Oops. Spelled fcntl.h wrong in the last one. D'uh. 2) PG_VERSION changed to be defined with " around it. psql/command.c failed to compile without that. 3) Changed makefiles to use "/MD" and link both psql and libpq.dll against MSVCRT.DLL instead of a static library. This takes care of the crash-upon-free in psql. I *think* this is what is on the "Open 7.1 Items" list as "Magnus Hagander ODBC Issues?". It has nothing to do with ODBC, but it's the only issue I've been involved with... Magnus Hagander
-
- 31 8月, 1999 1 次提交
-
-
由 Tom Lane 提交于
error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
-
- 16 8月, 1999 1 次提交
-
-
由 Tatsuo Ishii 提交于
Patches created by Hiroki Kataoka.
-
- 07 6月, 1999 1 次提交
-
-
由 Bruce Momjian 提交于
> (native win32, not cygnus). > It does the following: > Patches two win32.mak files to DEFINE HAVE_VSNPRINTF and > HAVE_STRDUP. This is required to build at all. > Bumps the version number on libpq.dll from 6.4 to 6.5. > Required for install programs to work. > Adds defintions for BLCKSZ and MAXIMUM_ALIGN to "win32.h" in > the client-side libpiq directory. > > All these files are only used when building on native win32, > so it should be safe I think. > > Again, really sorry to throw this in so late, but I would > hate to do the same thing as with 6.4 (which required 6.4.1 > to at all compile on Win32). > > Thanks, > > //Magnus
-
- 14 12月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
missed before the release. It's simply a symbol that is undefined. This patch defines this symbol in "win32.h", so it should have no effect on any other platforms. It should go into 6.4.1 if possible, since compilation is completely broken without it. I am also attaching a patch for the "win32.mak" file - it leaves a file behind when doing "make clean" after the library is built on Visual C++ 6.0. This is not at all as urgent, but I don't see it breaking here, so I think it might as well go in there too? //Magnus
-
- 06 10月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
regression test on a FreeBSD box with both non-MULTIBYTE and MULTIBYTE-enabled, and confirmed that the results are same. However I do not tested on PCs(I don't have access to win). Please let me know if the patches break anything on PCs. Also please note that the patch for varchar.c is a fix for a nasty bug of char(n) types that I introduced and I believe at least this should be applied. Tatsuo Ishii
-
- 19 9月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
Magnus Hagander
-
- 29 8月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
Here is a new patch for libpq, to make it work on Win32 again (since the latest modifications broke it a little). Please also add the file "libpq.rc" to the interfaces/libpq directory. This will allow version-stamping of the generated DLL file, so that automatic install programs (and interested users) can determine the version of the file. The file is currently set as "prerelease". Before the release, somebody should change the line "FILEFLAGS VS_FF_PRERELEASE" to "FILEFLAGS 0". That information should probably go into toos\RELEASE_CHANGES. The patch is against the cvs as of ~ 1998-08-26 14:30 CEST. //Magnus
-
- 03 7月, 1998 1 次提交
-
-
由 Bruce Momjian 提交于
Through some minor changes, I have been able to compile the libpq client libraries on the Win32 platform. Since the libpq communications part has been rewritten, this has become much easier. Enclosed is a patch that will allow at least Microsoft Visual C++ to compile libpq into both a static and a dynamic library. I will take a look at porting the psql frontend as well, but I figured it was a good idea to send in these patches first - so no major changes are done to the files before it gets applied (if it does). Regards, Magnus Hagander
-