Re: [PATCHES] Solve a problem of LC_TIME of windows.
Hi.
- Original Message -
From: "Alvaro Herrera" <[EMAIL PROTECTED]>
What about this line?
#define STRLEN_MAX 255
Are we really sure the strftime format cannot be longer than that?
Ahh, although the place to replace is here, is it said that MAX_L10 N_DATA is suitable?
--
cache_locale_time(void)
{
..
charbuf[MAX_L10N_DATA];
..
strftime(buf, MAX_L10N_DATA, "%a", timeinfo);
Regards,
Hiroshi Saito
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Solve a problem of LC_TIME of windows.
Hi. - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> In principle, I think this patch looks good. Do you (or somebody else) have an example where this breaks in an encoding where I can actually understand the characters, though ;-) That would make testing a whole lot easier... Also, the patch needs error checking. strftime() can fail, and the multibyte conversion functions can certainly fail. That will need to be added. Ok, thanks! strftime return to 0. http://msdn.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx MultiByteToWideChar and WideCharToMultiByte return to GetLastError. http://msdn.microsoft.com/en-us/library/ms776413(VS.85).aspx I will proposal the next patch.:-) BTW, this is SQL for a check. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK.sql Probably, all are included. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/LC_TIME_CHECK_LOCALE.sql Regards, Hiroshi Saito -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Solve a problem of LC_TIME of windows.
Hi. I have problem of LC_TIME of windows.(CVS-HEAD) As for Version 8.3.3. It is edited by wrong gettext and is. (But, it is expressed.) http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg8.3.3-to_char_gettext_format.png As for Version 8.4. It came to be used by Tom-san in strftime of Native-windowsAPI. It is good improvement.! But, strftime of Native returns a result by CODEPAGE of environment of operation by Windows with LC_TIME. In Japanese environment, return value is SJIS(CP932). Then, SJIS(CP932) can't be chosen by SERVER_ENCODING.:-( http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/pg84beta-03-to_char.png Then, I'm proposal patch. It is solved splendidly. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_EUCJP.txt http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_UTF8.txt Regards, Hiroshi Saito pg_locale_patch-v3 Description: Binary data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] win32mak of libpq patch
Hi. It seems that this is required in order to return the righter message. Please take into consideration. Thanks! Regards, Hiroshi Saito pg8.3.3_libpq_win32_patch Description: Binary data CVSHEAD_libpq_win32_patch Description: Binary data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] win32mak_patch
Hi Magnus. - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> Um, win32.mak of libpq needed to add dirmod.c -- libpq.lib(fe-connect.obj) : error LNK2001: (snip-sjis message) "_pgwin32_safestat" Then, Is containing in libpq wrong? I'm confused for a while... Yes, you are missing something :-) Ahh Sure, I had missed discussion of this improvement. Then, It seems that win32.mak has been forgotten. The patch for win32.mak I'm happy to apply, it looks fine. Yeah, Anyway I think that the equipment is required. The patch for exports.txt does not look fine. About it, I do not have firm belief yet. However, It does not put in there. Can you confirm that you can build things properly *with* the patch to win32.mak but *without* the patch to exports.txt? http://winpg.jp/~saito/pg_work/WIN32_BUILD_INF/psql_win32_n.mak I checked the build without correction of exports.txt. Also, I assume this needs to be backpatched? Yes, Since you have already done, I think that it is required. Thanks! Regards, Hiroshi Saito -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] win32mak_patch
Hi. Thanks! - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> Hiroshi Saito wrote: Hi. Eh? It is strange... http://winpg.jp/~saito/pg_work/WIN32_BUILD_INF/psql_win32.mak Actually, it is required although psql is built. Have I missed something? Note that building psql this way really isn't supported anymore :-) Yes, It is only a script for my check. :-) Anyway. If you get references to it, you need to pull in port/dirmod.c into psql as well. Normally, it would get this through libpgport, but it looks like your custom makfile is pulling the files in directly instead. So adding dirmod to the list of stuff from src/port should hopefully fix your problem. Um, win32.mak of libpq needed to add dirmod.c -- libpq.lib(fe-connect.obj) : error LNK2001: (snip-sjis message) "_pgwin32_safestat" Then, Is containing in libpq wrong? I'm confused for a while... Regards, Hiroshi Saito -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] win32mak_patch
Hi. Eh? It is strange... http://winpg.jp/~saito/pg_work/WIN32_BUILD_INF/psql_win32.mak Actually, it is required although psql is built. Have I missed something? Regards, Hiroshi Saito - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> The changes except the one to exports.txt look ok. Why do you need to export pgwin32_safestat? It's *not* exported when you build with mingw or the automated msvc build, and nothing breaks there. Who is trying to use it? //Magnus Hiroshi Saito wrote: Hi. Oops, Certainly. I propose the method of merging by distprep as exports.txt.win32. What do you think? Regards, Hiroshi Saito - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> > "Hiroshi Saito" <[EMAIL PROTECTED]> writes: >> *** src/interfaces/libpq/exports.txt.orig Sun Apr 27 23:41:51 2008 >> --- src/interfaces/libpq/exports.txt Sun Apr 27 23:42:48 2008 >> *** >> *** 141,143 >> --- 141,144 >> pg_valid_server_encoding_id 139 >> PQconnectionNeedsPassword 140 >> lo_import_with_oid 141 >> + pgwin32_safestat 142 > > > We are most certainly NOT doing that (for one reason, it will > instantly break every platform except Windows). If there is > something that seems to require it then you need to find another > way. > > regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] win32mak_patch
Hi. Oops, Certainly. I propose the method of merging by distprep as exports.txt.win32. What do you think? Regards, Hiroshi Saito - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> "Hiroshi Saito" <[EMAIL PROTECTED]> writes: *** src/interfaces/libpq/exports.txt.orig Sun Apr 27 23:41:51 2008 --- src/interfaces/libpq/exports.txt Sun Apr 27 23:42:48 2008 *** *** 141,143 --- 141,144 pg_valid_server_encoding_id 139 PQconnectionNeedsPassword 140 lo_import_with_oid 141 + pgwin32_safestat 142 We are most certainly NOT doing that (for one reason, it will instantly break every platform except Windows). If there is something that seems to require it then you need to find another way. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] win32mak_patch
Hi. Now, win32.mak of CVS-HEAD was left by the structural change. Please apply it. Regards, Hiroshi Saito win32mak_patch Description: Binary data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] ipcclean is excepted by windows.
>Hiroshi Saito wrote: >> Hi. >> >> As for windows, unnecessary garbage is processed. >> Please apply it. > >We have decided to remove ipcclean for all platforms so this patch is >no longer necessary. Yeah, thanks! Regards, Hiroshi Saito -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)
Hi. Um, my screen shot is looking at the problem. .. set LC_MESSAGES='de_DE.UTF-8'; .. it is not Japanese..however, result is Japanese message. From: "Gevik Babakhani" <[EMAIL PROTECTED]> Thank you. Is there any reason why JP locale files are not in normal installation? -Original Message- From: Hiroshi Saito [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 8:00 PM To: Magnus Hagander; Gevik Babakhani Cc: pgsql-patches@postgresql.org Subject: Re: [PATCHES] Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!) Hi. Sorry, I don't understand the point of this patch. However, reality was confirmed. I use "initdb -E UTF-8 --no-locale" Gevik-san patch apply it. (So, ja is not contained.) http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/Gevik_afterpatch.png Were you changeful before and after the correction? P.S) I was thinking about the improvement of other relations. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)
Hi. Sorry, I don't understand the point of this patch. However, reality was confirmed. I use "initdb -E UTF-8 --no-locale" Gevik-san patch apply it. (So, ja is not contained.) http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/Gevik_afterpatch.png Were you changeful before and after the correction? P.S) I was thinking about the improvement of other relations. Regards, Hiroshi Saito - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> Gevik Babakhani wrote: Hereby a patch that fixes NLS support on PG 8.3 compiled with MSVC. Haven't looked into the details of the patch yet, will do so. But the first thing I notice - you say this is only for MSVC, right? But the patch will also change the behaviour for the mingw build. Since you say you haven't tested on it, does the documentation imply that it would work on mingw, or is this likely to break that build? Perhaps it should be made conditional on MSVC only, and not on WIN32? //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] problem in win32.mak of 8.0.15
Hi. - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> On Fri, Feb 08, 2008 at 09:29:31PM +0900, Hiroshi Saito wrote: Hi Magnus. I received the problem of 8.0.15 from the user in Japan, and we understood that there was a patch forgotten per report KAZUYA-ozawa.(this is shift-jis) http://winpg.jp/~saito/pg80/error.txt Of course, this version is the outside for support. However, I want to leave record at least for the place of this ML. CVS-HEAD will be corrected if possible. Hi! As you have noted, 8.0 is not supported (and neither is 8.1) on Windows anymore, so I don't think we should apply this patch. Ah ok, I understand. As for CVS-HEAD - are you saying the problem happens there as well? If so we need a lot more details, because it seems to work for all others, including the buildfarm members... Oops, it is my typo. not CVS-HEAD, it is REL8_0_STABLE. Thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] problem in win32.mak of 8.0.15
Hi Magnus. I received the problem of 8.0.15 from the user in Japan, and we understood that there was a patch forgotten per report KAZUYA-ozawa.(this is shift-jis) http://winpg.jp/~saito/pg80/error.txt Of course, this version is the outside for support. However, I want to leave record at least for the place of this ML. CVS-HEAD will be corrected if possible. Thanks! Regards, Hiroshi Saito win32_patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Compile of Test example is put into win32.mak of libpq.
Hi. From: "Magnus Hagander" <[EMAIL PROTECTED]> On Thu, Jan 17, 2008 at 04:14:59PM +0900, Hiroshi Saito wrote: Hi. Hi. Sorry about the delay in the response. No problem. thanks. First: I needed other programs, in order to test what always built independent libpq.dll. Therefore, environment was considered variously. Then, I thought that a sample program was helpful. They are written to the document. Next: I understood that test example could not compile by MinGW (gcc). Furthermore, there was a problem of some MS-VC+. and, some difference was in the document and the program. However, It is not a problem in the reason a document is explanation in standard environment. probably. testlibpq4.c does not have description in a document. and, a program comment and operation were not in agreement...Therefore, a little change was given. I thinks that it is enough, in order to show an example. error happen before patch apply. http://winpg.jp/~saito/pg_work/testlibpq2.c.error http://winpg.jp/~saito/pg_work/testlibpq3.c.error I was able to do the satisfactory test after http://winpg.jp/~saito/pg_work/win32_i386_log.txt However, only compile was performed by the reason AMD64 does not have test environment..now. http://winpg.jp/~saito/pg_work/win32_AMD64_log.txt Please take this into consideration. I'm not sure we want to keep sticking these external makefiles for things. We specifically tried to get rid of a couple of those for 8.3 in other places. Ahh, If it becomes surely, I will desire to continue making psql from a pair for libpq. http://winpg.jp/~saito/pg83/WIN32_BUILD_INF/psql_win32.mak I always try actual operation, in order to check the accuracy of nmake independent libpq. I'm fine with the quick-fixes for the build. Why do you comment out a couple of lines from testlo.c? Ops, sorry...It was mistaken in confusion of work. "pickout" and "overwrite" also comment out the document so that they may see confusion of a result. Therfore, The same one as a document thought that it was good. Comments from others? //Magnus testlo_patch Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Compile of Test example is put into win32.mak of libpq.
Hi. First: I needed other programs, in order to test what always built independent libpq.dll. Therefore, environment was considered variously. Then, I thought that a sample program was helpful. They are written to the document. Next: I understood that test example could not compile by MinGW (gcc). Furthermore, there was a problem of some MS-VC+. and, some difference was in the document and the program. However, It is not a problem in the reason a document is explanation in standard environment. probably. testlibpq4.c does not have description in a document. and, a program comment and operation were not in agreement...Therefore, a little change was given. I thinks that it is enough, in order to show an example. error happen before patch apply. http://winpg.jp/~saito/pg_work/testlibpq2.c.error http://winpg.jp/~saito/pg_work/testlibpq3.c.error I was able to do the satisfactory test after http://winpg.jp/~saito/pg_work/win32_i386_log.txt However, only compile was performed by the reason AMD64 does not have test environment..now. http://winpg.jp/~saito/pg_work/win32_AMD64_log.txt Please take this into consideration. P.S) As for me, this is very helpful by the reason lost psql.exe in win32.mak. ! Regards, Hiroshi Saito pgsql_win32_example_patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] reference problem of manifest.(win32.mak of libpq.dll)
From: "Magnus Hagander" <[EMAIL PROTECTED]> I don't think of a good idea. However, since our document has announced officially, saying >=VC7.1. Therefore, I think that it is satisfactory. Ah, good point, I forgot about that. But - if we do that, why do we need that IF check *at all*? It is because it is saved by it although VC6 is private. probably, present all will be possible by it. I feel that it is better than exclusion for it. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] reference problem of manifest.(win32.mak of libpq.dll)
From: "Magnus Hagander" <[EMAIL PROTECTED]> Condition understanding of '>=' is not made as for namke of VC6 to a regrettable thing, but it causes an error to it:-( So, except all thought that it was good. Hmm. Crap. Perhaps there's something else we can check on? Like a feature or environment variable only present in newer versions or something? I don't think of a good idea. However, since our document has announced officially, saying >=VC7.1. Therefore, I think that it is satisfactory. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] reference problem of manifest.(win32.mak of libpq.dll)
Hi. - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> On Wed, Jan 09, 2008 at 04:01:20PM +0900, Hiroshi Saito wrote: Hi Magnus, and Dave. It seems that it is different in nmake although the initial value of VisualStudio is embedding. Then, It sees a reference problem by the dll independent. Therefore, embedding considers like an ideal. Please take this into consideration. + !IF "$(_NMAKE_VER)" != "6.00.9782.0" I don't think that's safe. We need to do a range check. Perhaps check if vesion is >= 7.0 or something? There can be other 6.00. versions, no? Say with different servicepacks or something? Condition understanding of '>=' is not made as for namke of VC6 to a regrettable thing, but it causes an error to it:-( So, except all thought that it was good. Regards, Hiroshi Saito ---(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
[PATCHES] reference problem of manifest.(win32.mak of libpq.dll)
Hi Magnus, and Dave. It seems that it is different in nmake although the initial value of VisualStudio is embedding. Then, It sees a reference problem by the dll independent. Therefore, embedding considers like an ideal. Please take this into consideration. Regards, Hiroshi Saito win32mak_patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] win32.mak patch
Hi Magnus. From: "Magnus Hagander" <[EMAIL PROTECTED]> I see the problem now. In my dev kit, there is no error for using _USE_32BIT_TIME_T on Win64. That's why I got caught up in your patch being wrong. Umm,... It is very strange.?_? C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(493) as below... -- #ifdef _USE_32BIT_TIME_T #ifdef _WIN64 #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 #undef _USE_32BIT_TIME_T #endif #else #if _INTEGRAL_MAX_BITS < 64 #define _USE_32BIT_TIME_T #endif #endif -- A question there though - do we care about the length of time_t on client platforms, or should we instead just disable the whole check for the client? AFAICS we don't expose time_t at all on the client, so why should we force libpq *clients* to build with 32-bit time_t? Shouldn't we go with the attached patch instead? It makes the win64 compile pass for me, but the linker step fails badly with: libpqdll.def : error LNK2001: unresolved external symbol PQbackendPID libpqdll.def : error LNK2001: unresolved external symbol PQbinaryTuples libpqdll.def : error LNK2001: unresolved external symbol PQcancel libpqdll.def : error LNK2001: unresolved external symbol PQclear for every export we have. Hiroshi, do you see that as well, or is something broken in my win64 environment? I'm running "nmake /f win32.mak CPU=AMD64" to build per our documentation, is that correct? Ah yes, however, the 64-bit build environment is created by the command which Microsoft offers. As for it, CPU=AMD64 is already defined. Then, I look at a good result after your patch. http://winpg.jp/~saito/pg83/WIN32MAK_AMD64_PATCH.txt Regards, Hiroshi Saito ---(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] win32.mak patch
Hi. - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> On Wed, Dec 19, 2007 at 11:19:54AM +0900, Hiroshi Saito wrote: Ummm, Sorry...former patch to be disregarded. Although 64bit mak is experimental, it needs to be compiled. Please apply this. Is this really correct? Fromw hat I can tell you *both* tell us not to check the value *and* set the value? Shouldn't we be doing just one of them? The setup is not allowed in 64-bit build of VisualStudio. Then, It is not allowed although I use nmake. I did the work of 64-bit correspondence of 8.3 to libpq. However, Although it is not declared by release, win32.mak has. I said that 64 bits of libpq(s) were required, in order that psqlODBC might guide 64 bits formally. Then, I and Inoue-san have lost timing in the reason for not having sufficient examination environment. But, We have compile environment. Then, It borrows an external machine and has performed only the easy examination -- add the _USE_32BIT_TIME_T for 64bit compile environment -- echo #define SYSCONFDIR "" > pg_config_paths.h cl.exe /nologo /W3 /EHsc /O2 /MD /I "..\..\include" /I "..\..\include\po rt\win32" /I "..\..\include\port\win32_msvc" /I "..\..\port" /I. /I "C:\OpenSSL\ include" /D "FRONTEND" /D NDEBUG /D _USE_32BIT_TIME_T /D "WIN32" /D "_WINDOWS" /Fp".\Release\libpq.pch" /Fo".\Release\\" /Fd".\Release\\" /FD /c /D "_CRT_S ECURE_NO_DEPRECATE" /D "WIN64" /Wp64 /GS /D ENABLE_THREAD_SAFETY "win32.c" win32.c C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(493) : fatal err or C1189: #error : You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Platform SDK\Bin\nmake.e xe"' : return code '0x2' Stop. -- END -- I'm always realistic. what do you think? Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] win32.mak patch
Ummm, Sorry...former patch to be disregarded. Although 64bit mak is experimental, it needs to be compiled. Please apply this. - Original Message - From: "Hiroshi Saito" <[EMAIL PROTECTED]> Hi Magnus. It is a thing left behind.:-( Please apply it. thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster win32mak_patch2 Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] win32.mak patch
Hi Magnus. It is a thing left behind.:-( Please apply it. thanks! Regards, Hiroshi Saito win32mak_patch Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] ipcclean is excepted by windows.
Hi. As for windows, unnecessary garbage is processed. Please apply it. Reagrds, Hiroshi Saito ipcclean_patch Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Adjustment of test_fsync.c
Hi Bruce-san. It is somewhat out of order at MinGW (gcc). (CVS-HEAD) make[1]: Leaving directory `/home/hiroshi/postgresql-8.3b1-2007-10-18/src/port' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-afterstatement -Wendif-labels -fno-strict-aliasing -I../../../src/interfaces/libpq -../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../../srcinclude/port/win32" -c -o test_fsync.o test_fsync.c test_fsync.c:75:39: macro "open" requires 3 arguments, but only 2 given test_fsync.c: In function `main': test_fsync.c:75: warning: assignment makes integer from pointer without a cast test_fsync.c:93:39: macro "open" requires 3 arguments, but only 2 given test_fsync.c:93: warning: assignment makes integer from pointer without a cast test_fsync.c:100:39: macro "open" requires 3 arguments, but only 2 given test_fsync.c:100: warning: assignment makes integer from pointer without a cast test_fsync.c:114:39: macro "open" requires 3 arguments, but only 2 given test_fsync.c:114: warning: assignment makes integer from pointer without a cast test_fsync.c:120:39: macro "open" requires 3 arguments, but only 2 given test_fsync.c:120: warning: assignment makes integer from pointer without a cast test_fsync.c:172:48: macro "open" requires 3 arguments, but only 2 given test_fsync.c:172: warning: assignment makes integer from pointer without a cast test_fsync.c:222:38: macro "open" requires 3 arguments, but only 2 given test_fsync.c:222: warning: assignment makes integer from pointer without a cast test_fsync.c:242:48: macro "open" requires 3 arguments, but only 2 given test_fsync.c:242: warning: assignment makes integer from pointer without a cast test_fsync.c:303:38: macro "open" requires 3 arguments, but only 2 given test_fsync.c:303: warning: assignment makes integer from pointer without a cast make: *** [test_fsync.o] Error 1 /END Please take this into consideration. Thanks. Regards, Hiroshi Saito test_fsync_patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] initdb of regression test failed.
Hi Tom-san. This may be mere information... In 8.3, when it has different encoding for every database, a locale requires C. Therefore, I am the reason which desires C by regression test. -- in>initdb -E EUC_JP -D../data --locale=Japanese_Japan.20932 The files belonging to this database system will be owned by user "hiroshi". This user must also own the server process. The database cluster will be initialized with locale Japanese_Japan.20932. initdb: could not find suitable text search configuration for locale "Japanese_J apan.20932" The default text search configuration will be set to "simple". creating directory ../data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers/max_fsm_pages ... 32MB/204800 creating configuration files ... ok creating template1 database in ../data/base/1 ... ok initializing pg_authid ... ok initializing dependencies ... ok creating system views ... ok loading system objects' descriptions ... ok creating conversions ... ok creating dictionaries ... ok setting privileges on built-in objects ... ok creating information schema ... ok vacuuming database template1 ... ok copying template1 to template0 ... ok copying template1 to postgres ... ok WARNING: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the -A option the next time you run initdb. Success. You can now start the database server using: -- in>psql template1 Welcome to psql 8.3devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit template1=# \l List of databases Name| Owner | Encoding ---+-+-- postgres | hiroshi | EUC_JP template0 | hiroshi | EUC_JP template1 | hiroshi | EUC_JP (3 rows) template1=# create database hiroshi; CREATE DATABASE template1=# \l List of databases Name| Owner | Encoding ---+-+-- hiroshi | hiroshi | EUC_JP postgres | hiroshi | EUC_JP template0 | hiroshi | EUC_JP template1 | hiroshi | EUC_JP (4 rows) template1=# show LC_CTYPE; lc_ctype -- Japanese_Japan.20932 (1 row) template1=# create database utfdb encoding='UTF8'; ERROR: encoding UTF8 does not match server's locale Japanese_Japan.20932 DETAIL: The server's LC_CTYPE setting requires encoding EUC_JP. template1=# ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] initdb of regression test failed.
Hi. Um, I thinks the examination material of 8.4 by the reason for changing the feature. Of course, your proposal can be considered to obtain one solution. Then, discussion is required more. I feel that it is dangerous for 8.3 Regards, Hiroshi Saito I wrote: I'll suggest to use UTF8 if the encoding is UTF-8 or NOT specified and we don't support the locale encoding on Windows, i.e. locale is always enabled on regression tests. Here is a patch to do it on Windows. 1. Use UTF-8 if the locale encoding is not available for server. 2. Allow mismatch between server and locale encodings if the server encoding is UTF-8. I succeeded to run regression test on Japanese version of Windows with the patch, but please test it on other language versions. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] initdb of regression test failed.
Oops, patch of pg_regress.c should be disregarded. Sorry, I think this is desirable. Hi. regression test surely goes wrong.! hedule --multibyte=SQL_ASCII --load-language=plpgsql == creating temporary installation== == initializing database system == pg_regress: initdb failed Examine ./log/initdb.log for the reason. Command was: ""C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb" -D "C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/data" -L "C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/share" --noclean > "./log/initdb.log" 2>&1" make[2]: *** [check] Error 2 make[2]: Leaving directory `/home/hiroshi/pgsql/src/test/regress' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/hiroshi/pgsql/src/test' make: *** [check] Error 2 -initdb.log- Running in noclean mode. Mistakes will not be cleaned up.^M The files belonging to this database system will be owned by user "hiroshi".^M This user must also own the server process.^M ^M The database cluster will be initialized with locale Japanese_Japan.932.^M initdb: locale Japanese_Japan.932 requires unsupported encoding SJIS^M Encoding SJIS is not allowed as a server-side encoding.^M Rerun initdb with a different locale selection.^M Running in noclean mode. Mistakes will not be cleaned up.^M - after the patch.. == shutting down postmaster == server stopped === All 112 tests passed. === Anyway, It surely fails now.:-( Regards, Hiroshi Saito regress_patch Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] initdb of regression test failed.
Hi. regression test surely goes wrong.! hedule --multibyte=SQL_ASCII --load-language=plpgsql == creating temporary installation== == initializing database system == pg_regress: initdb failed Examine ./log/initdb.log for the reason. Command was: ""C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb" -D "C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/data" -L "C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/share" --noclean > "./log/initdb.log" 2>&1" make[2]: *** [check] Error 2 make[2]: Leaving directory `/home/hiroshi/pgsql/src/test/regress' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/hiroshi/pgsql/src/test' make: *** [check] Error 2 -initdb.log- Running in noclean mode. Mistakes will not be cleaned up.^M The files belonging to this database system will be owned by user "hiroshi".^M This user must also own the server process.^M ^M The database cluster will be initialized with locale Japanese_Japan.932.^M initdb: locale Japanese_Japan.932 requires unsupported encoding SJIS^M Encoding SJIS is not allowed as a server-side encoding.^M Rerun initdb with a different locale selection.^M Running in noclean mode. Mistakes will not be cleaned up.^M - after the patch.. == shutting down postmaster == server stopped === All 112 tests passed. === Anyway, It surely fails now.:-( Regards, Hiroshi Saito pg_regress_patch Description: Binary data ---(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] initdb of regression test failed.
Hi. - Original Message - From: "ITAGAKI Takahiro" <[EMAIL PROTECTED]> "Hiroshi Saito" <[EMAIL PROTECTED]> wrote: Ah Ok, Please check it. Your patch looks useful to prevent mismatch of encoding and locale on Windows, but I found there is a limitation that user will not able to specify locale. I added an alternative of nl_langinfo(CODESET) for Win32. Please check following commands: initdb --encoding=EUC_jp --locale=Japanese_Japan.932 vs. initdb --encoding=EUC_jp --locale=Japanese_Japan.20932 One problem is that user need to know codepage numbers. It might be possible to replace the default codepage to server encodings automatically if we have a mapping table from encoding to codepage. Yes, I think your approach looks very good. Then, It seems that it is necessary to consider an original initial value problem again. I consider a document publication or management. Anyway, Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] initdb of regression test failed.
Hi. From: "ITAGAKI Takahiro" <[EMAIL PROTECTED]> "Hiroshi Saito" <[EMAIL PROTECTED]> wrote: The database cluster will be initialized with locale Japanese_Japan.932. initdb: locale Japanese_Japan.932 requires unsupported encoding SJIS Encoding SJIS is not allowed as a server-side encoding. - I think that the check of this server side is the right action.! I desire the further suggestion How about changing initdb to use encoding=UTF-8 and no-locale when the encoding of default locale is not suppoted in the server? I think it is the most frequently used combination when we cannot use the default encoding in server. Yeah, as for Japanese, your suggestion at least is right...I think. However, how is it in other countries? I worry about it... The present initdb without options always fails in such environments. Using UTF-8 with no-locale is better than error. (Error is better than using wrong locale, though.) Is a method specified and isn't it avoided by the document, rather than ad-hoc management? Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] initdb of regression test failed.
Hi. From: "Tom Lane" <[EMAIL PROTECTED]> "Hiroshi Saito" <[EMAIL PROTECTED]> writes: The database cluster will be initialized with locale Japanese_Japan.932. initdb: could not find suitable encoding for locale "Japanese_Japan.932" So, what encoding *should* we use for that locale? I think this is required We are certainly not going to disable pg_regress's ability to test in non-C locales. ISTM a proper fix is an addition to the table in src/port/chklocale.c. This example suggests actually that we need a boatload more table entries to handle Windows locale names :-( (count on Microsoft to ignore standards...) Ah Ok, Please check it. However, This problem - Running in noclean mode. Mistakes will not be cleaned up.^M The files belonging to this database system will be owned by user "hiroshi".^M This user must also own the server process.^M ^M The database cluster will be initialized with locale Japanese_Japan.932.^M initdb: locale Japanese_Japan.932 requires unsupported encoding SJIS^M Encoding SJIS is not allowed as a server-side encoding.^M Rerun initdb with a different locale selection.^M Running in noclean mode. Mistakes will not be cleaned up.^M - I think that the check of this server side is the right action.! I desire the further suggestion Regards, Hiroshi Saito chklocale_patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] initdb of regression test failed.
Hi Tom-san. initdb does not operate by the mismatch of LOCALE. - Running in noclean mode. Mistakes will not be cleaned up.^M The files belonging to this database system will be owned by user "hiroshi".^M This user must also own the server process.^M ^M The database cluster will be initialized with locale Japanese_Japan.932.^M initdb: could not find suitable encoding for locale "Japanese_Japan.932"^M Rerun initdb with the -E option.^M Try "initdb --help" for more information.^M Running in noclean mode. Mistakes will not be cleaned up.^M - I think this is required Did I miss something? Regards, Hiroshi Saito initdb_patch Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Loose check was corrected of win32.mak.
From: "Magnus Hagander" <[EMAIL PROTECTED]> + !MESSAGE nmake ended + !ERROR Make aorted. Apart from the spelling error on the second line, do we need the first line at all? It kind of says the same thing, but does nmake require a fixed number of rows or so? If not, I'll just take that away before committing. Ahhh... !ERROR Make aorted. Yeah Ok, Please only it. Thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] Loose check was corrected of win32.mak.
Hi Magnus. Loose check was corrected... and, It notifies an intelligible error message. Regards, Hiroshi Saito win32mak_patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] 64bit compile linker problem of win32.mak.
Hi Magnus. I saw one problem on Platform SDK. http://support.microsoft.com/kb/894573/en/ This can be helped. Thanks! Regards, Hiroshi Saito win32mak_patch Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Warning is adjusted of pgbench.
Hi. From: "Tom Lane" <[EMAIL PROTECTED]> Magnus Hagander <[EMAIL PROTECTED]> writes: On Tue, Aug 07, 2007 at 04:58:19PM +0900, Hiroshi Saito wrote: pgbench.c: In function `main': pgbench.c:1257: warning: implicit declaration of function `getopt' adjustment of some reference is required for this. Why do you need to #undef EXEC_BACKEND, and is there a specific reason for removing the include of win32.h? I've applied the attached modified version of this patch; it keeps win32.h in there (correctly re-marked as a system header). I think the fundamental issue must be that Hiroshi's system sets HAVE_GETOPT and HAVE_GETOPT_H. The former causes port.h to not supply a declaration of getopt(), so we'd better include to declare it. Together with the changes for FRONTEND applied a little bit ago, I hope that this issue is fully resolved in CVS HEAD. Let me know if there's still a problem. Yeah, I think that it felt it very refreshed.!:-) Though FRONTEND needs adjustment to consider carefully. Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Warning is adjusted of pgbench.
Hi. - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> Magnus Hagander <[EMAIL PROTECTED]> writes: On Thu, Sep 27, 2007 at 03:21:59PM +0900, Hiroshi Saito wrote: What do you think? I will be offline for most of the time for a couple of days, so it will probably be until early next week before I can look at this. Just a FYI, but I'll be happy to look at it as soon as I can. I like the FRONTEND solution, but not the EXEC_BACKEND stuff --- my objection there is that this formulation hard-wires EXEC_BACKEND to get defined only on a WIN32 build, which complicates testing that code on other platforms. (The whole point of the separate EXEC_BACKEND #define was to let non-Windows developers test that code path, remember.) Ah yes, I also worried that a little change might affect other platforms by the complexity of the action. we memorable it.. My feeling is that we should continue to have EXEC_BACKEND driven by CPPFLAGS, since that's easily tweaked on all platforms. I'm still not clear on why anything needs to be done with NON_EXEC_STATIC --- AFAICS that symbol is only referenced in half a dozen backend-only .c files, so I think we can just leave it as it stands. Although I am attached by the reason it happen the problem in a reference relation by windows, main() which it is called thinks in original that it is good by "non static". I look at that "non static ..main()" fully operates by FreeBSD. Does it influence performance? In the interests of pushing 8.3beta forward, I'm going to go ahead and commit this patch with the above mods; the buildfarm will let us know if there's anything seriously wrong ... Yeah, since it becomes better. thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Warning is adjusted of pgbench.
Hi. To be clear: my thought is to put "#define FRONTEND 1" into postgres_fe.h and then eliminate ad-hoc definitions of it from a boatload of Makefiles. A quick grep suggests that the only place this wouldn't work too well is src/port/, but that could keep on doing what it's doing. I tried it. and this is patch of test. Then, I still think that consideration is required to a slight degree involving port. However, This fully satisfied the following tests. (regression test is all pass) FreeBSD MinGW(gcc) MS-VC8 What do you think? Regards, Hiroshi Saito FRONTEND_PATCH Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Warning is adjusted of pgbench.
Hi. From: "Tom Lane" <[EMAIL PROTECTED]> "Hiroshi Saito" <[EMAIL PROTECTED]> writes: From: "Tom Lane" <[EMAIL PROTECTED]> Perhaps instead postgres_fe.h should #define FRONTEND? Yes, I feared that the physique of a main part broke. Then, Magnus said the same suggestion as you. It seems that it needs to be brushup. I am going to improve by the reason referred to as that FRONTEND influences nmake (libpq) again. Probably, Mugnus is operating main part.? To be clear: my thought is to put "#define FRONTEND 1" into postgres_fe.h and then eliminate ad-hoc definitions of it from a boatload of Makefiles. A quick grep suggests that the only place this wouldn't work too well is src/port/, but that could keep on doing what it's doing. I think sufficient suggestion. I'm not in a good position to test this, because it will mainly matter on Windows which I don't do. Anyone else have a chance to try it? I want, will try it. of course, work of Magnus is not barred. Thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Warning is adjusted of pgbench.
Hi. From: "Tom Lane" <[EMAIL PROTECTED]> "Hiroshi Saito" <[EMAIL PROTECTED]> writes: Why do you need to #undef EXEC_BACKEND, and is there a specific reason for removing the include of win32.h? I put in in order to avoid -D of the Makefile. If that matters, the problem is that somebody put the wrong stuff in the wrong include file. Backend-only things ought to go in postgres.h not c.h. In particular this is wrongly placed: /* EXEC_BACKEND defines */ #ifdef EXEC_BACKEND #define NON_EXEC_STATIC #else #define NON_EXEC_STATIC static #endif but AFAICS it doesn't affect anything that pgbench would care about. So I'm wondering *exactly* what goes wrong if you don't #undef EXEC_BACKEND in pgbench. As for the FRONTEND #define, that seems essential on Windows (and on no other platform) because port/win32.h uses it. But putting the #define into pgbench.c (and by implication into anything else we build on Windows) sure seems like a broken approach. Where else could we put it? It looks like right now that's left to the build system, which might or might not be a good idea, but if it is a good idea then pgbench must be getting missed. Perhaps instead postgres_fe.h should #define FRONTEND? Yes, I feared that the physique of a main part broke. Then, Magnus said the same suggestion as you. It seems that it needs to be brushup. I am going to improve by the reason referred to as that FRONTEND influences nmake (libpq) again. Probably, Mugnus is operating main part.? Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Warning is adjusted of pgbench.
Hi. Magnus $ make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -I../../src/interfaces/libpq -I. -I../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../src/include/port/win32" -c -o pgbench.o pgbench.c gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing pgbench.o -L../../src/port -lpgport -L../../src/interfaces/libpq -lpq -L../../src/port -Wl,--allow-multiple-definition -lpgport -lm -lws2_32 -lshfolder -o pgbench I put in in order to avoid -D of the Makefile. Regards, Hiroshi Saito On Tue, Aug 07, 2007 at 04:58:19PM +0900, Hiroshi Saito wrote: Hi Magnus. pgbench.c: In function `main': pgbench.c:1257: warning: implicit declaration of function `getopt' adjustment of some reference is required for this. and this is a FRONTEND program. patch is smooth at VC8 and MinGW (gcc). Hi! Why do you need to #undef EXEC_BACKEND, and is there a specific reason for removing the include of win32.h? //Magnus ---(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
[PATCHES] Warning is adjusted of pgbench.
Hi Magnus. pgbench.c: In function `main': pgbench.c:1257: warning: implicit declaration of function `getopt' adjustment of some reference is required for this. and this is a FRONTEND program. patch is smooth at VC8 and MinGW (gcc). Regards, Hiroshi Saito pgbench_patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Correction of how to use TimeZone by ControlFile(xlog.c)
Hi Tom-san. My it looks very great.!!! I was operating in the seen last night patch. Naturally, your thing is more great. Thank you very much!:-) Regards, Hiroshi Saito From: "Tom Lane" <[EMAIL PROTECTED]> Andrew Dunstan <[EMAIL PROTECTED]> writes: Tom's idea of a log_timezone seems to make sense. Here's a preliminary patch for this --- no docs yet, but code is all there. Seems to work OK. The patch is larger than it'd really have to be because I chose to rename global_timezone to session_timezone; I thought it'd be confusing to have something called "global_timezone" that actually has a narrower scope than "log_timezone". This wouldn't do for backpatching of course. My inclination for a backpatch is to just take %Z out of the strftime formats for Windows, as we did in several places already. Comments? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Correction of how to use TimeZone by ControlFile(xlog.c)
Andrew Dunstan <[EMAIL PROTECTED]> writes: Tom's idea of a log_timezone seems to make sense. I'll code that up and see if there are any unexpected gotchas. BTW, windows user should do how.? How do you think? Does it say "Set up an environment variable"? set TZ= Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Correction of how to use TimeZone by ControlFile(xlog.c)
"Hiroshi Saito" <[EMAIL PROTECTED]> writes: I understand the essence which you say. Then, I think that gmtime is an ideal there. localtime also takes summer time into consideration. It changes and sometimes falls unconsciously. Furthermore, a tzname can't be expressed by the present elog Moreover, how about relocating datacenter to New York from the loss Angelus? The log is continued database log is an audit item. Recently, it is more important than a response. And it is used secondarily. People who find the above arguments compelling would certainly be free to set their log_timezone to GMT. Those who don't find them compelling should not be forced to deal in GMT. The fact that Postgres has always logged in system local time, and we've had no complaints about that, suggests to me that most people prefer local-time logging. A certain user said. timezone of GUC is not effective with an elog output. I am, though it is an ideal that there is (e)log_timezone which you say.:-) Um, I think that only for PostgreSQL is good. BTW, windows user should do how.? Regards, Hiroshi Saito ---(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] Correction of how to use TimeZone by ControlFile(xlog.c)
Hi. From: "Tom Lane" <[EMAIL PROTECTED]> Gregory Stark <[EMAIL PROTECTED]> writes: "Tom Lane" <[EMAIL PROTECTED]> writes: I don't think it's an acceptable change in either place. People who want to see UTC in their logs can start the postmaster in UTC. Those who are accustomed to seeing local time will squawk. It would probably make sense to use UTC in the CSV logs since they're intended to be machine readable. Whatever program is used to read them can handle displaying the timestamps in the appropriate timezone for user's consumption. I don't think we really want to pay for formatting the timestamp twice (the existing patch goes out of its way to avoid that IIRC). About patch, it was only a thing for one solution. I thought that a next discussion was required for the problem which elog has. Thinking back, the major reason why we use platform strftime() here is to ensure that all backends will print log entries in the same timezone regardless of session settings of the TimeZone GUC. That decision was taken a long time ago, before we had the modern GUC infrastructure, and also before we had pgtz infrastructure that could efficiently handle conversions in multiple zones at once. Perhaps it would make sense to invent a system-wide (PGC_SIGHUP) variable "log_timezone" and use pg_strftime() with that setting to format timestamps for the log. Ah yes, I agreed on the worries about the change. That would eliminate platform variability of all kinds, not just the immediate Windows issue, and it might gain performance on some platforms (glibc in particular has a bad habit of doing a syscall for every strftime call). The only downside I can think of is that problems with the log_timezone setting could lead to recursive errors and eventual PANIC, but that's true of almost anything that goes wrong during error printout. I understand the essence which you say. Then, I think that gmtime is an ideal there. localtime also takes summer time into consideration. It changes and sometimes falls unconsciously. Furthermore, a tzname can't be expressed by the present elog Moreover, how about relocating datacenter to New York from the loss Angelus? The log is continued database log is an audit item. Recently, it is more important than a response. And it is used secondarily. What does a CSV output become in the latest feature? I am not good at explanation. However, I desire what you understand. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ODBC] [PATCHES] patch win32.mak of libpq
Hi Magnus. I'm sorry lateness of a reaction.. Thanks! P.S) Inoue-san is busy and worsens condition. Regards, Hiroshi Saito Ok. Just to be clear, do you need MSVC7.1 support, or do you need win32.mak/nmake support? I realize they both work here, but if we changed something else that needed MSVC8 but maintained the win32.mak file, would that be enough? Since I've had no further feedback, I've applied a patch that changes the list of supported MSVC versions to 7.1-8.0, but keeping the win32.mak files. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Correction of how to use TimeZone by ControlFile(xlog.c)
Hi Tom-san. From: "Tom Lane" "Hiroshi Saito" <[EMAIL PROTECTED]> writes: [ patch to use pg_strftime in xlog.c ] This code deliberately does not use pg_strftime, for the same reasons that elog.c doesn't use it. I'm inclined to think that an appropriate fix is the same as we use in elog.c, ie, don't use %Z at all under Windows. Eh? Do you mean this change? "%Y-%m-%d %H:%M:%S %Z" to "%Y-%m-%d %H:%M:%S" That tzname is expressed here does not regard me as a problem. Probably, elog.c has still more nearly another problem. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Correction of how to use TimeZone by ControlFile(xlog.c)
Hi. (sorry, this mail is UTF8) This problem is remarkable in the Japanese windows environment It appears in a log outputSee, - LOG: database system was shut down at 2007-07-31 19:23:25 東京 (標準時) LOG: database system is ready to accept connections LOG: autovacuum launcher started (This appears as SJIS in encoding of client in fact. Not server encoding..) So, It changes strikingly after patch.! - LOG: database system was shut down at 2007-08-01 10:15:12 JST LOG: database system is ready to accept connections LOG: autovacuum launcher started This is correctly treated by the timezone library with which PostgreSQL was equipped. Please take this into consideration. Thanks! Regards, Hiroshi Saito xlog_patch Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] patch win32.mak of libpq
Oops, An expressional mistake. As for PostgreSQL CVS HEAD(8.3beta). libpq is created by MinGW (gcc). As for psqlODBC CVS HEAD(08.02.0402) (linked SECUR32.dll) SECUR32.dll link is libpq.dll. SECUR32.dll does not link to psqlodbc35w.dll Regards, Hiroshi Saito ---(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] patch win32.mak of libpq
Hi. Some test situations. As for PostgreSQL CVS HEAD(8.3beta). libpq is created by MinGW (gcc). As for psqlODBC CVS HEAD(08.02.0402) (linked SECUR32.dll) 1. VC6(psqlodbc.dsp) The run test of compile and a part is through in VC6. 2. VC8(psqlodbc.vcproj) The run test of compile and a part is through in VC8. This is one progress report. It will still continue. However, the check was completed.! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] patch win32.mak of libpq
Hi Magnus and all. From: "Magnus Hagander" Hiroshi Saito wrote: Ok. So there are actually two ways to go about it: 1) Discontinue support for MSVC6 and require MSVC8 2) Change it so that MSVC6 can still build libpq, just not with SSPI support. This can be done by conditionally enabling ENABLE_SSPI, so it's not that hard. The question is, if we go with option 2, is it something that anybody actually will *use*? I desire 1 as formal. However, It contains VC7.1 and VC8. Moreover, libpq.dll can be used by the module of VC6. Is there any actual reason to keep VC7.1 support? It is still used and has sufficient function. Then, Inoue-san is developing in the environment.:-) The project file of VC7.1 differs from VC8 a little. However, nmake.exe absorbs it. for the reasons, we are maintaining win32.mak. but, project file offers the minimum function in simple. MSDTC is a reason for being somewhat more complicated than standard compile. VC6 has one reason only to exist, and that's that it doesn't carry the dependencies that VC8 does. But VC7 does (different ones, but just as many). So if we're dropping support for VC6, my suggestion is that we drop support for *any* win32 compiler other than VC8 and MingW gcc. By the PostgreSQL main part, I think that you may limit with support of VC7.1, VC8, and MinGW (gcc) by SSPI to which you are working. Although our psqlODBC uses libpq.dll, a wired protocol realizes it. Although I have not tested SSPI yet, However, I am checking normal of compile. If I'm not mistaken, one of the original reasons we kept the win32.mak method around after we had the "complete msvc build" was for the ODBC folks. Are you saying that the ODBC guys are now happy with a MSVC8 build? Yes, They are offered as comfortable environment. pgAdmin and that's right.!:-) However, psqlODBC also contains legacy VC6. They will clear a problem by the cause libpq.dll wire. Even if it may be adjusted from now on. probably. I'm sorry, I don't fully understand you here. Which one of the following three is it (or is it something else altogether)? 1) Does ODBC *require* a MSVC6 build libpq.dll? 2) Can ODBC work with MVC8 built libpq, but ODBC is built with MSVC6? 3) Can ODBC be built with MSVC8 and use the MSVC8 built libpq? It would be unfortunate if ODBC has to ship with a different set of dependencies than libpq, but as long as they build with either VC6 or VC8 that shouldn't happen. 1 above would be really bad, but I'm 99% sure that's not so, since I've actually tested SSPI auth with such a libpq. IMO, the best option would be 3, but I don't know enough about the ODBC driver to comment on there. I'll CC this to the odbc list so we can get more input from other people there. I'm sure that 3 is sufficient. I will begin the preparation. Of course, if there is a problem, though it will be corrected. P.S) The present situation.(as for psqlODBC) Compile (VC6, VC8) does not look at a problem by CVS-HEAD of pgsql.!! But, The test is not completedI apologize for the overdue work... Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] patch win32.mak of libpq
Hi. From: "Magnus Hagander" On Wed, Jul 25, 2007 at 10:30:29PM +0900, Hiroshi Saito wrote: >On Wed, Jul 25, 2007 at 02:36:41PM +0900, Hiroshi Saito wrote: >>Hi Magnus, and Dave. >> >>Sorry, I'm a somewhat late reaction... This is the present correspondence. >>However, VC6 does not support SSAPI. Therefore, the next release makes >>VC6 the outside of an object. > >I think VC6 should support it Ok. You probably just need to upgrade your >Platform SDK to a version that's for Windows 2000 or newer. I think VC6 >shipws with the NT4 SDK by default. It looks like it' just missing >secur32.lib. Ahh yes. However, MS says.! The last SDK that will work with VC 6.0 is the February 2003 Edition. http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ this SDK is newer and does not support VC6.:-( Ooh. Wasn't aware of that :-( Now I see what you mean. Yea, It is that there was nothing in public policy Ok. So there are actually two ways to go about it: 1) Discontinue support for MSVC6 and require MSVC8 2) Change it so that MSVC6 can still build libpq, just not with SSPI support. This can be done by conditionally enabling ENABLE_SSPI, so it's not that hard. The question is, if we go with option 2, is it something that anybody actually will *use*? I desire 1 as formal. However, It contains VC7.1 and VC8. Moreover, libpq.dll can be used by the module of VC6. If I'm not mistaken, one of the original reasons we kept the win32.mak method around after we had the "complete msvc build" was for the ODBC folks. Are you saying that the ODBC guys are now happy with a MSVC8 build? Yes, They are offered as comfortable environment. pgAdmin and that's right.!:-) However, psqlODBC also contains legacy VC6. They will clear a problem by the cause libpq.dll wire. Even if it may be adjusted from now on. probably. Thanks!! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] patch win32.mak of libpq
Hi Magnus. Thanks! From: "Magnus Hagander" On Wed, Jul 25, 2007 at 02:36:41PM +0900, Hiroshi Saito wrote: Hi Magnus, and Dave. Sorry, I'm a somewhat late reaction... This is the present correspondence. However, VC6 does not support SSAPI. Therefore, the next release makes VC6 the outside of an object. I think VC6 should support it Ok. You probably just need to upgrade your Platform SDK to a version that's for Windows 2000 or newer. I think VC6 shipws with the NT4 SDK by default. It looks like it' just missing secur32.lib. Ahh yes. However, MS says.! The last SDK that will work with VC 6.0 is the February 2003 Edition. http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ this SDK is newer and does not support VC6.:-( I have applied your patch, since it's used in either case. Thanks! If there is no objection. Let's close support of VC6. What do you think? While I don't disagree in principle, if you can test it with a new Platfrom SDK and see if that works there's no reason to close it (yet). It seems that it is difficult to get public although I have it. Then, I feel that support is difficult I missed something? Regards, Hiroshi Saito Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] patch win32.mak of libpq
Hi Magnus, and Dave. Sorry, I'm a somewhat late reaction... This is the present correspondence. However, VC6 does not support SSAPI. Therefore, the next release makes VC6 the outside of an object. -- VC6 Microsoft (R) Program Maintenance Utility Version 6.00.9782.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. Building the Win32 static library... Using default OpenSSL Include directory: C:\OpenSSL\include Using default OpenSSL Library directory: C:\OpenSSL\lib\VC Using default Kerberos Include directory: C:\kfw-2.6.5\inc Using default Kerberos Library directory: C:\kfw-2.6.5\lib\i386 echo #define SYSCONFDIR "" > pg_config_paths.h link.exe @C:\DOCUME~1\hiroshi\LOCALS~1\Temp\nma00120. LINK : fatal error LNK1181: (snip japanese) "secur32.lib" (snip japanese) NMAKE : fatal error U1077: 'link.exe' : (snip japanese) '0x49d' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\N MAKE.EXE"' : (snip japanese) '0x2' Stop. -- VC8 Microsoft(R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. Building the Win32 static library... Using default OpenSSL Include directory: C:\OpenSSL\include Using default OpenSSL Library directory: C:\OpenSSL\lib\VC Using default Kerberos Include directory: C:\kfw-2.6.5\inc Using default Kerberos Library directory: C:\kfw-2.6.5\lib\i386 link.exe @C:\DOCUME~1\hiroshi\LOCALS~1\Temp\nm969.tmp (snip japanese) .\Release\libpqdll.lib (snip japanese) .\Release\libpqdll.exp (snip japanese) cd ..\.. echo All Win32 parts have been built! All Win32 parts have been built! -- If there is no objection. Let's close support of VC6. What do you think? Regards, Hiroshi Saito win32.mak.patch Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Clear up strxfrm() in UTF-8 with locale on Windows
From: "ITAGAKI Takahiro" <[EMAIL PROTECTED]> The attached patch clears up the usage of strxfrm() on Windows. If the server encoding is UTF-8 and the locale is not C, we should use wcsxfrm() instead of strxfrm() because UTF-8 locale are not supported on Windows. We've already have a special version of strcoll() for Windows, but the usage of strxfrm() was still broken. When we are caught up in the bug, we see the next error message. | ERROR: invalid memory alloc request size 2147483648 If the server is wrong configured between the server encoding and the locale, strxfrm() could be failed and return values like INT_MAX or (size_t)-1. We've passed the result+1 straight to palloc(), so the server tried to allocale more than 1GB of memory and gave up. Ahh..., Certainly, the bug lurked there. probably, your patch will help it. It was not pursued in Japan for the reasons that the locale had been recommended to be used by C up to now. however, It seems to have caused the user's confusion. In that sense, I vote.+1 But, I am skeptic the locale setting still functions correctly. However, I think it is great work.:-) Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] I want to omit the fopen message of Windows.
Hi Tom-san. "Hiroshi Saito" <[EMAIL PROTECTED]> writes: Is this message necessary for setting errno again? AFAIR we only intended that message as a temporary measure until we'd figured out why things seemed to be failing on Windows. If there's no longer a need, I'd vote for removing the whole code chunk, not just stepping the level down by one. But if you are still seeing it, maybe we haven't figured out why the failure? Yes, it might be not necessary. I agrees. thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] I want to omit the fopen message of Windows.
Hi Magnus.
Is this message necessary for setting errno again?
LOG: database system was interrupted; last known up at 2007-02-28 14:42:27 JST
LOG: Windows fopen("recovery.conf","r") failed: code 2, errno 2
LOG: Windows fopen("pg_xlog/0001.history","r") failed: code 2, errno 2
LOG: Windows fopen("backup_label","r") failed: code 2, errno 2
LOG: checkpoint record is at 0/4C54A8
LOG: redo record is at 0/4C54A8; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 0/599; next OID: 11468
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery in progress
LOG: record with zero length at 0/4C54F8
LOG: redo is not required
LOG: Windows fopen("global/pg_fsm.cache","rb") failed: code 2, errno 2
LOG: database system is ready to accept connections
LOG: Windows fopen("global/pgstat.stat","rb") failed: code 2, errno 2
LOG: autovacuum launcher started
I have misgivings about user's surprise.. You have already completed
debugging.:-)
Therefore, it wants to make it omit at the DEBUG1 level.
Regards,
Hiroshi Saito
fd.c_patch
Description: Binary data
---(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
[pgsql-patches] pthread option of msvc build.
Hi Magnus-san. I am trying simple construction by operating config.pl. It has changed wonderfully now. however, I do not use ecpg, and see the simplest construction. At that time, even pthread might not be needed. It was simple. Please consider this. P.S) I can't catch up with your quick work. However, I will try the debugging execution with VS2005 by the arrangement option. tools/msvc will surely facilitate debugging.! Thanks. Regards, Hiroshi Saito msvc_patch Description: Binary data ---(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] win32.mak patch of pg_dump.
Hi. The module link is insufficient.:-( Sorry, japanese message change to xxx --- link.exe @C:\DOCUME~1\hi-saito\LOCALS~1\Temp\nmk03360. common.obj : error LNK2001: xx "_pg_qsort" xx pg_dump_sort.obj : error LNK2001: x "_pg_qsort" x .\Release\pg_dump.exe : fatal error LNK1120: xxx NMAKE : fatal error U1077: 'link.exe' : x '0x460' Stop. ---- Please apply it. Thanks. Regards, Hiroshi Saito pg_dump_win32_patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] patch of Encoding problem
Hi. I think this problem to be complex http://archives.postgresql.org/pgsql-hackers/2006-11/msg00042.php FormatMessage of windows cannot consider the encoding of the database. However, I should try the solution now. It is necessary to clear the problem. Multi character-code exists together in message and log. It doesn't consider the data base encoding that the user intended The user in multi-byte country can try this. http://inet.winpg.jp/~saito/pg_bug/MessageCheck.c That is, it is likely to become it in this manner.(Japanese) http://inet.winpg.jp/~saito/pg_bug/FormatMessage998.png Therefore, I hope for treatment that replaces these messages with English that is neutrality. Regards, Hiroshi Saito FormatMessage_patch Description: Binary data ---(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] test_fsync on MinGW(win32)
Hi. I wanted to see this difference. It is somewhat ad hoc. However, It is more effective than it doesn't show it at all. -- MinGW(win32) -- $ test_fsync Simple write timing: write3.644000 Compare fsync times on write() and non-write() descriptor: (If the times are similar, fsync() can sync data written on a different descriptor.) write, fsync, close 40.543000 write, close, fsync 47.033000 Compare one o_sync write to two: (o_sync unavailable) open o_dsync, write 0.094000 (fdatasync unavailable) write, fsync, 26.70 Compare file sync methods with 2 8k writes: open o_dsync, write 0.203000 (fdatasync unavailable) write, fsync, 27.92 Regards, Hiroshi Saito test_fsync_patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] warning: "min" redefined of qsort.
Hi Tom-san. From: "Tom Lane" "Hiroshi Saito" <[EMAIL PROTECTED]> writes: I have warning with MinGW qsort.c:53:1: warning: "min" redefined I've fixed this by using Min() from c.h instead. Ahh, I was consideration shortage. Thanks!! Regards, Hiroshi Saito ---(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] warning: "min" redefined of qsort.
Hi. I have warning with MinGW qsort.c:53:1: warning: "min" redefined In file included from C:/MinGW/include/windows.h:48, from ../../src/include/pg_config_os.h:12, from ../../src/include/c.h:88, from qsort.c:46: C:/MinGW/include/windef.h:143:1: warning: this is the location of the previous definition qsort_arg.c:53:1: warning: "min" redefined In file included from C:/MinGW/include/windows.h:48, from ../../src/include/pg_config_os.h:12, from ../../src/include/c.h:88, from qsort_arg.c:46: C:/MinGW/include/windef.h:143:1: warning: this is the location of the previous definition qsort.c:53:1: warning: "min" redefined In file included from C:/MinGW/include/windows.h:48, from ../../src/include/pg_config_os.h:12, from ../../src/include/c.h:88, from qsort.c:46: C:/MinGW/include/windef.h:143:1: warning: this is the location of the previous definition qsort_arg.c:53:1: warning: "min" redefined In file included from C:/MinGW/include/windows.h:48, from ../../src/include/pg_config_os.h:12, from ../../src/include/c.h:88, from qsort_arg.c:46: Therefore, please consider this. Regards, Hiroshi Saito qsort_win32_patch Description: Binary data ---(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] win32 client build patch
Hi Bruce-san. This is required in spite of being legacy. Please apply it.(this is the situation of current cvs.) Thanks. Regards, Hiroshi Saito win32_patch Description: Binary data ---(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] related problem of path by msvc
Hi Magnus. From: "Magnus Hagander" This patch looks like it has some weird combination of unix and windows line endings. Was that intentional? Ea? No, did I miss something? Regards, Hiroshi Saito ---(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] related problem of path by msvc
Ah...I am sorry in spam mail.:-(
It is this surely..
Sorry..all
Hiroshi Saito
Uga...short..
Sorry this is new patch.
--- src/tools/msvc/build.bat.orig Fri Sep 8 11:49:32 2006
+++ src/tools/msvc/build.batFri Sep 8 11:50:37 2006
@@ -4,7 +4,7 @@
perl mkvcbuild.pl
if errorlevel 1 goto :eof
-if exist ..\vcbuild if exist ..\src cd ..
+if exist ..\..\..\src\tools\msvc if exist ..\..\..\src cd ..\..\..
if "%1" == "" msbuild pgsql.sln
if not "%1" == "" vcbuild %1.vcproj
--- src/tools/msvc/mkvcbuild.pl.origFri Sep 8 11:49:45 2006
+++ src/tools/msvc/mkvcbuild.pl Fri Sep 8 11:52:36 2006
@@ -5,12 +5,12 @@
use Project;
use Solution;
-chdir('..') if (-d '..\vcbuild' && -d '..\src');
-die 'Must run from root directory or vcbuild directory' unless (-d 'vcbuild'
&& -d 'src');
-die 'Could not find config.pl' unless (-f 'vcbuild/config.pl');
+chdir('..\..\..') if (-d '..\..\..\src\tools\msvc' && -d '..\..\..\src');
+die 'Must run from root directory or vcbuild directory' unless (-d 'src/tools/msvc'
&& -d 'src');
+die 'Could not find config.pl' unless (-f 'src/tools/msvc/config.pl');
our $config;
-require 'vcbuild/config.pl';
+require 'src/tools/msvc/config.pl';
my $solution = new Solution($config);
--- src/tools/msvc/Project.pm.orig Fri Sep 8 12:13:23 2006
+++ src/tools/msvc/Project.pm Fri Sep 8 13:14:34 2006
@@ -286,13 +286,13 @@
my $of = $f;
$of =~ s/\.y$/.c/;
$of =~
s{^src\\pl\\plpgsql\\src\\gram.c$}{src\\pl\\plpgsql\\src\\pl_gram.c};
- print F '>' . "\n";
+ print F '>' . "\n";
}
elsif ($f =~ /\.l$/) {
my $of = $f;
$of =~ s/\.l$/.c/;
$of =~
s{^src\\pl\\plpgsql\\src\\scan.c$}{src\\pl\\plpgsql\\src\\pl_scan.c};
- print F ">\n";
+ print F ">\n";
}
elsif (defined($uniquefiles{$file})) {
# File already exists, so fake a new name
@@ -362,7 +362,7 @@
print $f "\t{name}\\$self->{name}.lib\" IgnoreDefaultLibraryNames=\"libc\"
/>\n";
print $f "\t\n";
if ($self->{builddef}) {
- print $f "\t{name}\" />\n";
+ print $f "\t{name}\" />\n";
}
print $f <
--- src/tools/msvc/Solution.pm.orig Fri Sep 8 12:15:06 2006
+++ src/tools/msvc/Solution.pm Fri Sep 8 12:15:30 2006
@@ -21,8 +21,8 @@
# Special case - if config.pl has changed, always return 1
sub IsNewer {
my ($newfile, $oldfile) = @_;
- if ($oldfile ne 'vcbuild\config.pl') {
- return 1 if IsNewer($newfile, 'vcbuild\config.pl');
+ if ($oldfile ne 'src\tools\msvc\config.pl') {
+ return 1 if IsNewer($newfile, 'src\tools\msvc\config.pl');
}
return 1 if (!(-e $newfile));
my @nstat = stat($newfile);
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] related problem of path by msvc
Uga...short..
Sorry this is new patch.
- Original Message -
From: "Hiroshi Saito" <[EMAIL PROTECTED]>
To:
Sent: Friday, September 08, 2006 12:02 PM
Subject: [PATCHES] related problem of path by msvc
Hi Bruce-san, and Magnus-san.
I have one problem, after this is arranged.
Please take into consideration.
Regards,
Hiroshi Saito
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
--- src/tools/msvc/build.bat.orig Fri Sep 8 11:49:32 2006
+++ src/tools/msvc/build.batFri Sep 8 11:50:37 2006
@@ -4,7 +4,7 @@
perl mkvcbuild.pl
if errorlevel 1 goto :eof
-if exist ..\vcbuild if exist ..\src cd ..
+if exist ..\..\..\src\tools\msvc if exist ..\..\..\src cd ..\..\..
if "%1" == "" msbuild pgsql.sln
if not "%1" == "" vcbuild %1.vcproj
--- src/tools/msvc/mkvcbuild.pl.origFri Sep 8 11:49:45 2006
+++ src/tools/msvc/mkvcbuild.pl Fri Sep 8 11:52:36 2006
@@ -5,12 +5,12 @@
use Project;
use Solution;
-chdir('..') if (-d '..\vcbuild' && -d '..\src');
-die 'Must run from root directory or vcbuild directory' unless (-d 'vcbuild'
&& -d 'src');
-die 'Could not find config.pl' unless (-f 'vcbuild/config.pl');
+chdir('..\..\..') if (-d '..\..\..\src\tools\msvc' && -d '..\..\..\src');
+die 'Must run from root directory or vcbuild directory' unless (-d 'src/tools/msvc'
&& -d 'src');
+die 'Could not find config.pl' unless (-f 'src/tools/msvc/config.pl');
our $config;
-require 'vcbuild/config.pl';
+require 'src/tools/msvc/config.pl';
my $solution = new Solution($config);
--- src/tools/msvc/Project.pm.orig Fri Sep 8 12:13:23 2006
+++ src/tools/msvc/Project.pm Fri Sep 8 12:14:51 2006
@@ -286,13 +286,13 @@
my $of = $f;
$of =~ s/\.y$/.c/;
$of =~
s{^src\\pl\\plpgsql\\src\\gram.c$}{src\\pl\\plpgsql\\src\\pl_gram.c};
- print F '>' . "\n";
+ print F '>' . "\n";
}
elsif ($f =~ /\.l$/) {
my $of = $f;
$of =~ s/\.l$/.c/;
$of =~
s{^src\\pl\\plpgsql\\src\\scan.c$}{src\\pl\\plpgsql\\src\\pl_scan.c};
- print F ">\n";
+ print F ">\n";
}
elsif (defined($uniquefiles{$file})) {
# File already exists, so fake a new name
@@ -362,7 +362,7 @@
print $f "\t{name}\\$self->{name}.lib\" IgnoreDefaultLibraryNames=\"libc\"
/>\n";
print $f "\t\n";
if ($self->{builddef}) {
- print $f "\t{name}\" />\n";
+ print $f "\t{name}\" />\n";
}
print $f <
--- src/tools/msvc/Solution.pm.orig Fri Sep 8 12:15:06 2006
+++ src/tools/msvc/Solution.pm Fri Sep 8 12:15:30 2006
@@ -21,8 +21,8 @@
# Special case - if config.pl has changed, always return 1
sub IsNewer {
my ($newfile, $oldfile) = @_;
- if ($oldfile ne 'vcbuild\config.pl') {
- return 1 if IsNewer($newfile, 'vcbuild\config.pl');
+ if ($oldfile ne 'src\tools\msvc\config.pl') {
+ return 1 if IsNewer($newfile, 'src\tools\msvc\config.pl');
}
return 1 if (!(-e $newfile));
my @nstat = stat($newfile);
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
[PATCHES] related problem of path by msvc
Hi Bruce-san, and Magnus-san.
I have one problem, after this is arranged.
Please take into consideration.
Regards,
Hiroshi Saito
--- src/tools/msvc/build.bat.orig Fri Sep 8 11:49:32 2006
+++ src/tools/msvc/build.batFri Sep 8 11:50:37 2006
@@ -4,7 +4,7 @@
perl mkvcbuild.pl
if errorlevel 1 goto :eof
-if exist ..\vcbuild if exist ..\src cd ..
+if exist ..\..\..\src\tools\msvc if exist ..\..\..\src cd ..\..\..
if "%1" == "" msbuild pgsql.sln
if not "%1" == "" vcbuild %1.vcproj
--- src/tools/msvc/mkvcbuild.pl.origFri Sep 8 11:49:45 2006
+++ src/tools/msvc/mkvcbuild.pl Fri Sep 8 11:52:36 2006
@@ -5,12 +5,12 @@
use Project;
use Solution;
-chdir('..') if (-d '..\vcbuild' && -d '..\src');
-die 'Must run from root directory or vcbuild directory' unless (-d 'vcbuild'
&& -d 'src');
-die 'Could not find config.pl' unless (-f 'vcbuild/config.pl');
+chdir('..\..\..') if (-d '..\..\..\src\tools\msvc' && -d '..\..\..\src');
+die 'Must run from root directory or vcbuild directory' unless (-d 'src/tools/msvc'
&& -d 'src');
+die 'Could not find config.pl' unless (-f 'src/tools/msvc/config.pl');
our $config;
-require 'vcbuild/config.pl';
+require 'src/tools/msvc/config.pl';
my $solution = new Solution($config);
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
[PATCHES] Adjustment of compile of ms-vc8
Hi Bruce-san. I desired a little adjustments by ms-vc8. The existing version with which the security of many functions is not strengthened is no longer used. In order to repeal warning which tells no longer being used, it is about _CRT_SECURE_NO_DEPRECATE. A definition is given it. P.S) I am sorry in repeated patch of a bit Regards, Hiroshi Saito win32_vc8ref_patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] clear mistake of win32
Hi Bruce-san. It was the mistake of description. Thanks. Regards, Hiroshi Saito win32_clean_patch Description: Binary data ---(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] Fixed definition of complicated errcode of ms_vc8
Hi Bruce-san. "errcode" definition complains from each definition of windows. c:\home\postgresql-8.2devel-20060805\src\include\utils/elog.h(105) : error C2365: 'errcode' : (snip) C:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(506) : 'errcode' (snip) This patch was avoided by vc8. Thanks. Regards, Hiroshi Saito ms_vc8_patch Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] patch of libpq-int.h is required of msvc.
Hi Bruce-san. patch of libpq-int.h is required of msvc. I think that this definition changed. cl.exe /nologo /W3 /GX /O2 /MD /I "..\..\include" /I "..\..\include\port \win32" /I "..\..\include\port\win32_msvc" /I "..\..\port" /I. /D "FRONTEND" /D NDEBUG /D "WIN32" /D "_WINDOWS" /Fp".\Release\libpq.pch" /YX /Fo".\Release\\" /F d".\Release\\" /FD /c /D "HAVE_VSNPRINTF" /D "HAVE_STRDUP" "fe-auth.c" fe-auth.c libpq-int.h(481) : error C2061: (snip) Regards, Hiroshi Saito msvc_patch Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Patch for VS.Net 2005's strxfrm() bug
From: "Florian G. Pflug" Ahhh, It is right.! I was retracing my memory for what situations the contents were. I was in distraction.It seems that it is satisfactory at the reason for ==. Sorry and Thanks.!! Regards, Hiroshi Saito Bruce Momjian wrote: Why is this better than: #if _MSC_VER == 1400 Surely this will not be true if _MSC_VER is undefined? I experienced injustice and the reason of in OSX for it. What was the problem with OSX? Did it throw a warning of you did an equality test on an undefined symbol? The following if evaluated to true on osx, although I'm pretty sure that _MSC_VER isn't defined on osx ;-) #if (_MSC_VER < 1300) ... #endif replacing it with #ifdef WIN32 #if (_MSC_VER < 1300) ... #endif #endif fixed the problem. greetings, Florian Pflug ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] Patch for VS.Net 2005's strxfrm() bug
From: "Andrew Dunstan" > Hiroshi Saito wrote: > > Hmm, It seems to be the bug of very unpleasant Microsoft.:D > > I think that the following is desirable as an evasion measure to add. > > > > #if defined(_MSC_VER) && _MSC_VER == 1400 > > > > To be sure, it was only VS2005. > > > > > Why is this better than: > > #if _MSC_VER == 1400 > > > Surely this will not be true if _MSC_VER is undefined? I experienced injustice and the reason of in OSX for it. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Patch for VS.Net 2005's strxfrm() bug
Hi.
"William ZHANG" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> When I tried to compile pgsql-8.2devel with VS.Net 2005 and do regression
> tests,
> I found the problem. It's a bug inVS.Net 2005:
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=99694
>
+ /*
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=99694
*/
+ #if _MSC_VER == 1400
+ {
+char x[1];
+
+xfrmlen = strxfrm(x, val, 0);
+ }
+ #else
xfrmlen = strxfrm(NULL, val, 0);
+ #endif
Hmm, It seems to be the bug of very unpleasant Microsoft.:D
I think that the following is desirable as an evasion measure to add.
#if defined(_MSC_VER) && _MSC_VER == 1400
To be sure, it was only VS2005.
Regards,
Hiroshi Saito
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] PostmasterHandl_patch of win32
From: "Tom Lane" "Hiroshi Saito" <[EMAIL PROTECTED]> writes: Probably, this application will be required. This seems very messy. The correct fix is just to put back the #include line, no? @@ -18,6 +18,7 @@ #include #include "miscadmin.h" +#include "postmaster/postmaster.h" #include "storage/pmsignal.h" #include "storage/shmem.h" Ahh.., include by which you were committed is very good. Thanks.! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] PostmasterHandl_patch of win32
Hi Bruce-san. Uga..., include is removed and it is out of order. pmsignal.c: In function `PostmasterIsAlive': pmsignal.c:121: error: `PostmasterHandle' undeclared (first use in this function) pmsignal.c:121: error: (Each undeclared identifier is reported only once pmsignal.c:121: error: for each function it appears in.) make[4]: *** [pmsignal.o] Error 1 make[3]: *** [ipc-recursive] Error 2 make[2]: *** [storage-recursive] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 Probably, this application will be required. P.S) In addition, there are some problems. It is corrected soon. Regards, Hiroshi Saito PostmasterHandl_patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] c.h is the problem of msvc.
Hi Bruce-san. Umm, c.h is the problem of msvc. getaddrinfo.c ..\..\include\c.h(63) : fatal error C1083: 'crtdefs.h': No such file or directory does not exist in vs2003... problem is solved by removing this before vs2005. moreover, nothing does not run short by it. Regards, Hiroshi Saito msvc_c_patch Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Client build of MSVC6+ patch
Hi. Tom-san. Oops, I understood it. Thank you for suggestion. What condition is this? Regards, Hiroshi Saito From: "Tom Lane" "Hiroshi Saito" <[EMAIL PROTECTED]> writes: Why do we need to reorder the fields in the struct? Eh? Even my FreeBSD used well shows a structure object. The standard lists the fields in the other order: http://www.opengroup.org/onlinepubs/009695399/basedefs/netdb.h.html Even though the standard doesn't say that that has to be the physical order, every other platform besides Windows does it that way. The patch as given is unacceptable because it *will* break other platforms (mine for instance ;-)). If it has to be this way for Windows then we need some sort of platform-specific #ifdef. Considering that the code works as-is on several sorts of Windows builds, we probably need something even more specific than that, like #if MSVC-before-version-XX. regards, tom lane getaddrinfo_patch2 Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Client build of MSVC6+ patch
Hi.
If IPv6 gets broken after all the trouble several of us went to I'll
be annoyed. :-)
Um, I think that this was the origin in problem.:-)
Why do we need to reorder the fields in the struct?
Eh? Even my FreeBSD used well shows a structure object.
(FreeBSD)
/usr/include/netdb.h
struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
int ai_family; /* PF_xxx */
int ai_socktype;/* SOCK_xxx */
int ai_protocol;/* 0 or IPPROTO_xxx for IPv4 and IPv6 */
size_t ai_addrlen; /* length of ai_addr */
char*ai_canonname; /* canonical name for hostname */
struct sockaddr *ai_addr; /* binary address */
struct addrinfo *ai_next; /* next structure in linked list */
};
Then, It was helped actually.
Regards,
Hiroshi Saito
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Client build of MSVC6+ patch
Hi. If IPv6 gets broken after all the trouble several of us went to I'll be annoyed. :-) Um, I think that this was the origin in problem.:-) Regards, Hiroshi Saito getaddrinfo_patch Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Client build of MSVC6+ patch
Hi Bruce-san, and Magnus-san. I take out patch for this as a promise. This is client-build support of MS-VC6+. However, It leaves the problem of IPV6.:-( Regards, Hiroshi Saito msvc_patch Description: Binary data ---(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
[PATCHES] pg_backup_tar.c seems anerror by win32
Hi Bruce-san. Yesterday patch was inadequate pg_backup_tar.c: In function `tarOpen': pg_backup_tar.c:379: `S_IREAD' undeclared (first use in this function) pg_backup_tar.c:379: (Each undeclared identifier is reported only once pg_backup_tar.c:379: for each function it appears in.) pg_backup_tar.c:379: `S_IWRITE' undeclared (first use in this function) pg_backup_tar.c: In function `_tarAddFile': pg_backup_tar.c:1051: warning: comparison is always false due to limited range of data type make[3]: *** [pg_backup_tar.o] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all] Error 2 make: *** [all] Error 2 This patch helps this. Thanks. Regards, Hiroshi Saito pg_backup_tar.c_patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] MS-VC build patch
Umm, It is strange.. I think that you have another config.h.? I look at much error by the reason for being realistic. I will become on tomorrow night, since I am not in the machine which can work now. Regards, Hiroshi Saito From: "Magnus Hagander" Hi Bruce-san. It does not help me yet. He uses VC2005.:-( It seems that furthermore, it is still in the middle of work. One problem is visible to the next.(win32.mak) + if not exist pg_config_os.h copy port\win32.h pg_config_os.h If VC6+ is still supported, I will submit the patch again. What I patch has built both the client and the server by VC6+. I don't think there's anything specific in my patch that should kill VC6. What specifically does not work in VC6? (Just reverting the whole patch doesn't seem right to me...) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] MS-VC build patch
Hi Bruce-san. It does not help me yet. He uses VC2005.:-( It seems that furthermore, it is still in the middle of work. One problem is visible to the next.(win32.mak) + if not exist pg_config_os.h copy port\win32.h pg_config_os.h If VC6+ is still supported, I will submit the patch again. What I patch has built both the client and the server by VC6+. Regards, Hiroshi Saito From: "Bruce Momjian" > > Hiroshi, I applied Magnus's patches. Can you build cleanly now? > > ------- > > Hiroshi Saito wrote: > > Hi Bruce-san, and Magnus-san, > > > > I have many problems by client construction of 8.2. > > This patch helps a MS-VC client and server construction. > > However, IPV6 still has the problem. > > Please fully take into consideration. > > > > Thanks. > > > > Regards, > > Hiroshi Saito > > > > [ Attachment, skipping... ] > > > > > ---(end of broadcast)--- > > TIP 6: explain analyze is your friend > > -- > Bruce Momjian [EMAIL PROTECTED] > EnterpriseDBhttp://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] MS-VC build patch
Hi Bruce-san, and Magnus-san, I have many problems by client construction of 8.2. This patch helps a MS-VC client and server construction. However, IPV6 still has the problem. Please fully take into consideration. Thanks. Regards, Hiroshi Saito pgsql82dev_win_patch Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] The problem of an inline definition by construction in win32 of 8.1.4
Dear Bruce san. I neglected sufficient test before a release.:-( Problem appears by construction in win32 of 8.1.4. nmake -f win32.mak ".\Release\\" /FD /c /D "HAVE_VSNPRINTF" /D "HAVE_STRDUP" "pqexpbuffer.c" pqexpbuffer.c cl.exe /nologo /W3 /GX /O2 /MD /I "..\..\include" /I. /D "FRONTEND" /D N DEBUG /D "WIN32" /D "_WINDOWS" /Fp".\Release\libpq.pch" /YX /Fo".\Release\\" /Fd ".\Release\\" /FD /c /D "HAVE_VSNPRINTF" /D "HAVE_STRDUP" "pqsignal.c" pqsignal.c cl.exe @C:\DOCUME~1\saito\LOCALS~1\Temp\nmi02992. wchar.c ..\..\backend\utils\mb\wchar.c(100) : error C2054: 'inline' ..\..\backend\utils\mb\wchar.c(101) : error C2085: 'pg_euc_mblen' (snip) It is not mingw. Regards, Hiroshi Saito win32_patch Description: Binary data ---(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] Encryption of .pgpass
From: "Tom Lane" <[EMAIL PROTECTED]> > What is the point of this? It seems to be complicating life to little > purpose (except storing passwords that will fail in non-MD5 password > methods --- given that people are talking about replacing MD5, that > doesn't seem like a good forward-looking idea). Ahh, yes. It is "crypt" ,"ident" and "pam"... I do not think that "passwd" should be used primarily. Then, So, it is clear sufix of md5. It may be a narrower use. However, I have simplified that it can use as a method of hiding it. It is suggestion. Is it accepted by including "crypt"? Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Encryption of .pgpass
Dear Bruce san. I may be quite persistent.:-) I seasoned the proposal method. It was very painful that the conventional connection method to this password was a plain text. Although I am simple, I desire the support. Furthermore, the relation between a field item and an environment variable is complicated. ex.) inetrt% pqpasswd -U postgres -d postgres New Password: Retype New Password: Succeeded in creation. inetrt% pqpasswd -U postgres -d postgres -l /home/saito/.pgpass hostname=localhost port=5432 dbname=postgres username=postgres password=** This 1th line is used. inetrt% cat /home/saito/.pgpass localhost:5432:postgres:postgres:postgres inetrt% psql postgres postgres Welcome to psql 8.2devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# inetrt% rm /home/saito/.pgpass inetrt% pqpasswd -U postgres -d postgres -m New Password: Retype New Password: Succeeded in creation. inetrt% pqpasswd -U postgres -d postgres -m -l /home/saito/.pgpass.md5 hostname=localhost port=5432 dbname=postgres username=postgres password=** This 1th line is used. inetrt% cat /home/saito/.pgpass.md5 localhost:5432:postgres:postgres:md53175bce1d3201d16594cebf9d7eb3f9d inetrt% psql postgres postgres Welcome to psql 8.2devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# inetrt% rm /home/saito/.pgpass.md5 inetrt% psql postgres postgres Password for user postgres: Welcome to psql 8.2devel, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit I tried correspondence by sufix of md5 to .pgpass, in order to maintain compatibility. I wish that it is fully reviewed. Thanks. Regards, Hiroshi Saito pqpasswd_patch Description: Binary data ---(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] Building with Visual C++
Hi Magnus. I understood that this helped. #define PGBINDIR "/usr/local/pgsql/bin" #define PGSHAREDIR "/usr/local/pgsql/share" #define SYSCONFDIR "/usr/local/pgsql/etc" #define INCLUDEDIR "/usr/local/pgsql/include" #define PKGINCLUDEDIR "/usr/local/pgsql/include" #define INCLUDEDIRSERVER "/usr/local/pgsql/include/server" #define LIBDIR "/usr/local/pgsql/lib" #define PKGLIBDIR "/usr/local/pgsql/lib" #define LOCALEDIR "" #define DOCDIR "/usr/local/pgsql/doc" #define MANDIR "/usr/local/pgsql/man" It reconstructed on VC++6 with a part of your patch. Then, I am very good touch.:-) However, Would you add another patch of this? Regards, Hiroshi Saito --- src/include/port/win32.h.orig Mon May 8 14:45:11 2006 +++ src/include/port/win32.hMon May 8 15:15:09 2006 @@ -1,5 +1,8 @@ /* $PostgreSQL: pgsql/src/include/port/win32.h,v 1.51 2006/03/03 20:52:36 momjian Exp $ */ +#ifndef _PORT_WIN32_H +#define _PORT_WIN32_H + /* undefine and redefine after #include */ #undef mkdir @@ -11,6 +14,7 @@ #include #undef near +#define near pg_near /* Must be here to avoid conflicting with prototype in windows.h */ #define mkdir(a,b) mkdir(a) @@ -256,3 +260,5 @@ /* in backend/port/win32/error.c */ extern void _dosmaperr(unsigned long); + +#endif /* _PORT_WIN32_H */ --- src/include/getaddrinfo.h.orig Mon May 8 14:35:41 2006 +++ src/include/getaddrinfo.h Mon May 8 14:36:54 2006 @@ -43,7 +43,9 @@ #define EAI_SYSTEM (-11) #else /* WIN32 */ #if defined(WIN32_CLIENT_ONLY) +#ifndef WSA_NOT_ENOUGH_MEMORY #define WSA_NOT_ENOUGH_MEMORY (WSAENOBUFS) +#endif #define WSATYPE_NOT_FOUND (WSABASEERR+109) #endif #define EAI_AGAIN WSATRY_AGAIN ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Building with Visual C++
From: "Magnus Hagander" I am sorry in a very late reaction... >>> We'll need a VC buildfarm member in place to catch us anytime we >>> change the Makefiles in a way that the script doesn't understand. >> >> Not a problem - Snake has VC++ 6, 2003 and 2005 installed. This is a trial in the reason I have not fully investigated your code yet. And construction was tried by VC++6. It contains some problems. I know that this differs from the solution which you consider. However, I have some hope. As for present condition is the following situations. 1) Complain by access of a data directory. C:\pgsql>bin\initdb -E EUC_JP --no-locale -Ddata -LC:/pgsql/share The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. initdb: could not access directory "data": No error 2) $libdir is not looked for. C:\pgsql>bin\initdb -E EUC_JP --no-locale -Ddata -LC:/pgsql/share The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers/max_fsm_pages ... 4000/20 creating configuration files ... ok creating template1 database in data/base/1 ... ok initializing pg_authid ... ok enabling unlimited row size for system tables ... ok initializing dependencies ... ok creating system views ... ok loading system objects' descriptions ... ok creating conversions ... FATAL: could not access file "$libdir/ascii_and_mic": No such file or directory child process was terminated by signal 1 initdb: removing contents of data directory "data" 3) could not select a suitable default timezone. C:\pgsql>bin\postmaster -i -Ddata FATAL: could not select a suitable default timezone DETAIL: It appears that your GMT time zone uses leap seconds. PostgreSQL does not support leap seconds. --- However, it shows sufficient reaction. :-) Although arrangement has not been carried out yet, a source code does not become dirty so much. This is a source code and a binary.(sorry, not diffs text.) http://inetrt.skcapi.co.jp/~saito/pgsql82dev/ I also want this approach to be included in the following version. Some of any suggestion? Regards, Hiroshi Saito ---(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] Native-win32 patch
Hi Bruce-san. Some of these progress of me is glad.:-) Please apply it. Thanks. Regards, Hiroshi Saito pg82devel_win32_patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] To build client can on Windows using Microsoft Visual C++
Dear Bruce san. I think that a certain user has a meaning as for this client construction. There is a user who demands to build only by Microsoft thoroughly. However, it may be ignored if support load is disliked. What is necessary will be just to remain in a mail archive, even if this is not applied. Thanks.! Regards, Hiroshi Saito --- doc/src/sgml/install-win32.sgml.origFri Jan 6 14:09:29 2006 +++ doc/src/sgml/install-win32.sgml Fri Jan 6 15:06:49 2006 @@ -83,13 +83,27 @@ +bin\pg_config\Release\pg_config.exe bin\psql\Release\psql.exe +bin\pg_dump\Release\pg_dump.exe +bin\pg_dump\Release\pg_dumpall.exe +bin\pg_dump\Release\pg_restore.exe +bin\scripts\Release\clusterdb.exe +bin\scripts\Release\createdb.exe +bin\scripts\Release\createuser.exe +bin\scripts\Release\createlang.exe +bin\scripts\Release\dropdb.exe +bin\scripts\Release\dropuser.exe +bin\scripts\Release\droplang.exe +bin\scripts\Release\vacuumdb.exe +bin\scripts\Release\reindexdb.exe - The PostgreSQL interactive terminal + The PostgreSQL client applications and utilities. + --- src/bin/pg_dump/pg_backup_archiver.c.orig Thu Jan 5 15:09:55 2006 +++ src/bin/pg_dump/pg_backup_archiver.cThu Jan 5 15:10:50 2006 @@ -27,7 +27,10 @@ #include "dumputils.h" #include + +#ifndef WIN32_CLIENT_ONLY #include +#endif #ifdef WIN32 #include --- src/bin/pg_dump/pg_backup_db.c.orig Thu Jan 5 15:09:55 2006 +++ src/bin/pg_dump/pg_backup_db.c Thu Jan 5 15:11:01 2006 @@ -15,7 +15,10 @@ #include "pg_backup_db.h" #include "dumputils.h" +#ifndef WIN32_CLIENT_ONLY #include +#endif + #include #ifdef HAVE_TERMIOS_H --- src/bin/pg_dump/pg_backup_null.c.orig Thu Jan 5 15:09:55 2006 +++ src/bin/pg_dump/pg_backup_null.cThu Jan 5 15:11:13 2006 @@ -25,7 +25,9 @@ #include "pg_backup.h" #include "pg_backup_archiver.h" +#ifndef WIN32_CLIENT_ONLY #include/* for dup */ +#endif #include "libpq/libpq-fs.h" --- src/bin/pg_dump/pg_backup_tar.c.origThu Jan 5 15:09:55 2006 +++ src/bin/pg_dump/pg_backup_tar.c Thu Jan 5 15:11:25 2006 @@ -27,7 +27,10 @@ #include #include + +#ifndef WIN32_CLIENT_ONLY #include +#endif static void _ArchiveEntry(ArchiveHandle *AH, TocEntry *te); static void _StartData(ArchiveHandle *AH, TocEntry *te); --- src/bin/pg_dump/pg_dump.c.orig Thu Jan 5 15:09:55 2006 +++ src/bin/pg_dump/pg_dump.c Thu Jan 5 15:11:36 2006 @@ -24,7 +24,10 @@ */ #include "postgres.h" +#ifndef WIN32_CLIENT_ONLY #include +#endif + #include #ifdef ENABLE_NLS #include --- src/bin/pg_dump/pg_dumpall.c.orig Thu Jan 5 15:09:55 2006 +++ src/bin/pg_dump/pg_dumpall.cThu Jan 5 15:11:54 2006 @@ -14,7 +14,11 @@ #include "postgres_fe.h" #include + +#ifndef WIN32_CLIENT_ONLY #include +#endif + #ifdef ENABLE_NLS #include #endif --- src/bin/pg_dump/pg_restore.c.orig Thu Jan 5 15:09:55 2006 +++ src/bin/pg_dump/pg_restore.cThu Jan 5 15:12:06 2006 @@ -53,7 +53,9 @@ #include #endif +#ifndef WIN32_CLIENT_ONLY #include +#endif #include "getopt_long.h" --- src/bin/pg_dump/win32.mak.orig Thu Jan 5 15:20:24 2006 +++ src/bin/pg_dump/win32.mak Fri Jan 6 10:49:49 2006 @@ -0,0 +1,186 @@ +# Makefile for Microsoft Visual C++ 5.0 (or compat) + +!IF "$(OS)" == "Windows_NT" +NULL= +!ELSE +NULL=nul +!ENDIF + +CPP=cl.exe +PERL=perl.exe +FLEX=flex.exe +YACC=bison.exe +MV=move + +!IFDEF DEBUG +OPT=/Od /Zi /MDd +LOPT=/DEBUG +DEBUGDEF=/D _DEBUG +OUTDIR=.\Debug +INTDIR=.\Debug +!ELSE +OPT=/O2 /MD +LOPT= +DEBUGDEF=/D NDEBUG +OUTDIR=.\Release +INTDIR=.\Release +!ENDIF + +REFDOCDIR= ../../../doc/src/sgml/ref + +CPP_PROJ=/nologo $(OPT) /W3 /GX /D "WIN32" $(DEBUGDEF) /D "_CONSOLE" /D\ + "_MBCS" /Fp"$(INTDIR)\pg_dump.pch" /YX /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\\" /FD /c \ + /I ..\..\include /I ..\..\interfaces\libpq /I ..\..\include\port\win32 /I ..\..\backend \ + /D "HAVE_STRDUP" /D "FRONTEND" + +CPP_OBJS=$(INTDIR)/ +CPP_SBRS=. + +ALL : ..\..\backend\parser\parse.h "..\..\port\pg_config_paths.h" \ + "$(OUTDIR)\pg_dump.exe" "$(OUTDIR)\pg_dumpall.exe" "$(OUTDIR)\pg_restore.exe" + +CLEAN : + [EMAIL PROTECTED] "$(INTDIR)\pg_backup_archiver.obj" + [EMAIL PROTECTED] "$(INTDIR)\pg_backup_db.obj" + [EMAIL PROTECTED] "$(INTDIR)\pg_backup_custom.obj" + [EMAIL PROTECTED] "$(INTDIR)\pg_backup_files.obj" + [EMAIL PROTECTED] "$(INTDIR)\pg_backup_null.obj" + [EMAIL PROTECTED] "$(INTDIR)\pg_backup_tar.obj" + [EMAIL PROTECTED] "$(INTDIR)\dumputils.obj" + [EMAIL PROTECTED] "$(INTDIR)\common.obj" + [EMAIL PROTECTED] "$(INT
Re: [PATCHES] display and expression of the home directory in Win32
From: "Magnus Hagander" HOMEDIR = "C:/Documents and Settings/saito/Application Data/postgresql" VERSION = PostgreSQL 8.1.1 HOMEDIR is a very bad name for this variable, since it's *not* the home directory. It could easily be confused. If we put it in, I definitly think it should be called something else.. (USERCONFDIR based on that we Um, About a name, I think that it is right. have SYSCONFDIR, perhaps?). Also, there is no reason not to include it on Unix as well - it would actrually be much better to do that, in case someone wants to write a script that relies on it. It will be good to be clearly shown in all environments. dir "C:/Documents and Settings/saito/Application Data/postgresql" This would then be: dir "%APPDATA%\postgresql" which is actually much easier to use than getting it from pg_config, since you can use the environment variable in any command you want. Probably, there is a user who notices after the directory is shown. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] display and expression of the home directory in Win32
Dear Bruce san.
I receive an inquiry from a user frequently. Where is it about a home
directory in a place? Then, In offer of the initial state of Windows,
the place is hidden and is not visible to a user. I considered what can
be offered this way and that. Then, using pg_config thinks that it is good.
This patch show a user a clear place. Please take this into consideration.
F:\postgresql-8.1.2stable\src\bin\pg_config\Release>pg_config.exe
BINDIR = F:/postgresql-8.1.2stable/src/bin/pg_config/Release
DOCDIR =
INCLUDEDIR =
PKGINCLUDEDIR =
INCLUDEDIR-SERVER =
LIBDIR =
PKGLIBDIR =
LOCALEDIR =
MANDIR =
SHAREDIR =
SYSCONFDIR =
PGXS = /pgxs/src/makefiles/pgxs.mk
HOMEDIR = "C:/Documents and Settings/saito/Application Data/postgresql"
VERSION = PostgreSQL 8.1.1
dir "C:/Documents and Settings/saito/Application Data/postgresql"
2005/08/10 11:19 .
2005/08/10 11:19 ..
2005/08/10 11:19 0 pgpass.conf
2005/01/13 00:00 3,520 postgresql.crt
2005/01/13 00:00 891 postgresql.key
Regards,
Hiroshi Saito
--- src/bin/pg_config/pg_config.c.orig Fri Jan 6 10:16:56 2006
+++ src/bin/pg_config/pg_config.c Fri Jan 6 10:49:23 2006
@@ -29,6 +29,17 @@
static const char *progname;
static char mypath[MAXPGPATH];
+#ifdef WIN32
+#ifdef _WIN32_IE
+#undef _WIN32_IE
+#endif
+#define _WIN32_IE 0x0500
+#ifdef near
+#undef near
+#endif
+#define near
+#include
+#endif
/*
* This function cleans up the paths for use with either cmd.exe or Msys
@@ -47,6 +58,7 @@
#ifdef WIN32
char *ptr;
+#ifndef WIN32_CLIENT_ONLY
if (GetShortPathName(path, path, MAXPGPATH - 1) == 0)
{
/*
@@ -59,7 +71,7 @@
return;
}
}
-
+#endif /* !WIN32_CLIENT_ONLY */
/* Replace '\' with '/' */
for (ptr = path; *ptr; ptr++)
{
@@ -364,6 +376,25 @@
printf("PostgreSQL " PG_VERSION "\n");
}
+#ifdef WIN32
+static void
+show_homedir(bool all)
+{
+ charhomedir[MAXPGPATH];
+
+ if (all)
+ printf("HOMEDIR = ");
+
+ ZeroMemory(homedir, sizeof(homedir));
+ SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, homedir);
+ cleanup_path(homedir);
+#ifdef WIN32_CLIENT_ONLY
+ printf("\"%s/postgresql\"\n", homedir);
+#else
+ printf("%s/postgresql\n", homedir);
+#endif
+}
+#endif
/*
* Table of known information items
@@ -397,6 +428,9 @@
{"--ldflags", show_ldflags},
{"--ldflags_sl", show_ldflags_sl},
{"--libs", show_libs},
+#ifdef WIN32
+ {"--homedir", show_homedir},
+#endif
{"--version", show_version},
{NULL, NULL}
};
@@ -431,6 +465,9 @@
printf(_(" --ldflags show LDFLAGS value used when
PostgreSQL was built\n"));
printf(_(" --ldflags_sl show LDFLAGS_SL value used when
PostgreSQL was built\n"));
printf(_(" --libsshow LIBS value used when PostgreSQL
was built\n"));
+#ifdef WIN32
+ printf(_(" --homedir show HOME directry of owner user\n"));
+#endif
printf(_(" --version show the PostgreSQL version\n"));
printf(_(" --helpshow this help, then exit\n"));
printf(_("\nWith no arguments, all known items are shown.\n\n"));
---(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] CVS of 8.1.x MS-VC6 probrem.
Dear tom san. Thank you for suggestion. > Yeah. I had hoped the client-only build would "just work" with the > snprintf changes, but if not there is no time to make it work for 8.1.1. > I would like to revisit this for 8.1.2 or 8.2, though. It would be > good to have NLS support in the client-only build, if we intend to keep > supporting that at all. > > regards, tom lane Actually, it is possible by only replacing DLL of making MSVC of now with DLL of MinGW now. I think that I am satisfactory by MSVC DLL of the present simple structure. Isn't it satisfied only with explaining of it? It will be satisfied if simple MSVC is provided with compile environment. Otherwise, even kerberos5 is possible. However, I vote for Magnus. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] CVS of 8.1.x MS-VC6 probrem.
Hi Magnus. > > libpq and psql also have message translation. > > AFAIK we don't support NLS builds with MSVC anyway. (Check > pg_config.h.win32, it has no #define NLS). So I don't think this is an > issue. Um, I agree with you. Probably, Bruce san is also noticed. I thought that Bruce san suggested the evolution. However, I think that the plan is now difficult for 8.1.1. Regards, Hiroshi Saito ---(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
