Re: [HACKERS] How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?
Hi MauMau-san it my bug patch applied to ver 1.6.2sorry.. then, I made the next patch is there, please see, http://winpg.jp/~saito/pg_work/OSSP_win32/ I will be adjusted and Ralf-san again. best regards, Hiroshi Saito (2013/10/30 21:45), MauMau wrote: Hello, # Sorry, Saito san' address doesn't seem to exist, so excuse for sending again For a certain reason, I need to build PostgreSQL on Windows with OSSP UUID support to use UUID for primary keys. I have to use Visual Studio 2010. The original source code for OSSP UUID and its fork for Windows can be downloaded from: http://www.ossp.org/pkg/lib/uuid/ http://sourceforge.jp/projects/sfnet_osspuuidwin32/ I built the latest version 1.6.2 and used uuid_generate_v4() as the default value for a primary key column of type uuid. However, when I insert 200-300 rows, an unique constraint violation error is reported. It occurs repeatedly in several retries. I found some people hit the same problem in the past, but they didn't seem to get the solution: http://www.postgresql.org/message-id/039e01c8b63c$d0c95e90$60096cdb@IBMC9A0F63B40D http://www.postgresql.org/message-id/018d01c8dec6$2a14b470$0b01a8c0@IBMC9A0F63B40D http://www.postgresql.org/message-id/98B20744191F464DB598A25AB00BC125@acer08f817a9b5 When I copy lib\uuid_ossp.dll in the PostgreSQL community package, which I guess Dave Page san maintains, to my installation, the error does not occur. So, OSSP UUID library is the cause. Saito san published a patch for OSSP UUID on his site: http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/ And Dave san showed interest in it: http://www.postgresql.org/message-id/snt127-w18c42125e5fd719ba514ceff...@phx.gbl How can I build the OSSP UUID library that functions properly on Windows? Is OSSP UUID 1.6.2 + Saito-san's patch the exact source for the uuid-ossp.dll in thecommunity binary? Regards MauMau -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] problem of win32.mak
Hi Magnus-san and Bruce-san. I am sorry in a very late reaction... Is it enough for a 9.1release? libpq of bcc32 and win32 has a problem. == error of nmake == ライブラリ .\Release\libpqdll.lib とオブジェクト .\Release\libpqdll.exp を作成中 libpq.lib(fe-connect.obj) : error LNK2019: 未解決の外部シンボル _inet_net_ntop が関数 _connectFailureMessage で参照されました。 libpq.lib(getaddrinfo.obj) : error LNK2001: 外部シンボル _inet_net_ntop は未解決です。 libpq.lib(fe-connect.obj) : error LNK2019: 未解決の外部シンボル _pg_get_encoding_from_locale が関数 _PQsetClientEncoding で参照されました。 .\Release\libpq.dll : fatal error LNK1120: 外部参照 2 が未解決です。 == end == Please take this into consideration. Thanks. Regards, Hiroshi Saito *** src/interfaces/libpq/bcc32.mak.old Fri Aug 19 06:23:13 2011 --- src/interfaces/libpq/bcc32.mak Wed Sep 7 21:50:33 2011 *** *** 80,85 --- 80,87 -@erase $(INTDIR)\inet_aton.obj -@erase $(INTDIR)\crypt.obj -@erase $(INTDIR)\noblock.obj + -@erase $(INTDIR)\chklocale.obj + -@erase $(INTDIR)\inet_net_ntop.obj -@erase $(INTDIR)\md5.obj -@erase $(INTDIR)\ip.obj -@erase $(INTDIR)\fe-auth.obj *** *** 123,128 --- 125,132 $(INTDIR)\inet_aton.obj \ $(INTDIR)\crypt.obj \ $(INTDIR)\noblock.obj \ + $(INTDIR)\chklocale.obj \ + $(INTDIR)\inet_net_ntop.obj \ $(INTDIR)\md5.obj \ $(INTDIR)\ip.obj \ $(INTDIR)\fe-auth.obj \ *** *** 220,225 --- 224,239 $(INTDIR)\noblock.obj : ..\..\port\noblock.c $(CPP) @ $(CPP_PROJ) ..\..\port\noblock.c + + + $(INTDIR)\chklocale.obj : ..\..\port\chklocale.c + $(CPP) @ + $(CPP_PROJ) ..\..\port\chklocale.c + + + $(INTDIR)\inet_net_ntop.obj : ..\..\port\inet_net_ntop.c + $(CPP) @ + $(CPP_PROJ) ..\..\port\inet_net_ntop.c $(INTDIR)\md5.obj : ..\..\backend\libpq\md5.c *** src/interfaces/libpq/win32.mak.old Fri Aug 19 06:23:13 2011 --- src/interfaces/libpq/win32.mak Wed Sep 7 21:45:22 2011 *** *** 87,92 --- 87,94 -@erase $(INTDIR)\inet_aton.obj -@erase $(INTDIR)\crypt.obj -@erase $(INTDIR)\noblock.obj + -@erase $(INTDIR)\chklocale.obj + -@erase $(INTDIR)\inet_net_ntop.obj -@erase $(INTDIR)\md5.obj -@erase $(INTDIR)\ip.obj -@erase $(INTDIR)\fe-auth.obj *** *** 132,137 --- 134,141 $(INTDIR)\inet_aton.obj \ $(INTDIR)\crypt.obj \ $(INTDIR)\noblock.obj \ + $(INTDIR)\chklocale.obj \ + $(INTDIR)\inet_net_ntop.obj \ $(INTDIR)\md5.obj \ $(INTDIR)\ip.obj \ $(INTDIR)\fe-auth.obj \ *** *** 258,263 --- 262,277 $(INTDIR)\noblock.obj : ..\..\port\noblock.c $(CPP) @ $(CPP_PROJ) ..\..\port\noblock.c + + + $(INTDIR)\chklocale.obj : ..\..\port\chklocale.c + $(CPP) @ + $(CPP_PROJ) ..\..\port\chklocale.c + + + $(INTDIR)\inet_net_ntop.obj : ..\..\port\inet_net_ntop.c + $(CPP) @ + $(CPP_PROJ) ..\..\port\inet_net_ntop.c $(INTDIR)\md5.obj : ..\..\backend\libpq\md5.c -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] problem of win32.mak
Hi. We are looking forward to the great release. thanks again!! Regards, Hiroshi Saito (2011/09/07 23:46), Magnus Hagander wrote: On Wed, Sep 7, 2011 at 16:43, Bruce Momjianbr...@momjian.us wrote: Hiroshi Saito wrote: Hi Magnus-san and Bruce-san. I am sorry in a very late reaction... Is it enough for a 9.1release? libpq of bcc32 and win32 has a problem. == error of nmake == ? .\Release\libpqdll.lib ??? .\Release\libpqdll.exp libpq.lib(fe-connect.obj) : error LNK2019: ?? _inet_net_ntop ??? _connectFailureMessage ? libpq.lib(getaddrinfo.obj) : error LNK2001: ?? _inet_net_ntop ??? libpq.lib(fe-connect.obj) : error LNK2019: ?? _pg_get_encoding_from_locale ??? _PQsetClientEncoding ? .\Release\libpq.dll : fatal error LNK1120: 2 ??? == end == Yes, this is a problem. I will apply your patch to 9.1 and head unless I hear otherwise in a few hours. Looks fine to me, go ahead. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Full GUID support
Hi Thomas-san, Ralf-san. I appreciate your great work. Thanks! CC to Postgres-ML. Regards, Hiroshi Saito (2011/07/14 3:49), Thomas Lotterer wrote: Thanks for the hint. Our ftp daemon is dumping core. We are debugging ... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Full GUID support
Um, Although I have not caught up with this thread. Ralf-san and the member of OSSP are maintaining OSSP continuously. I think that a reaction can merely be obtained in the intervals of when busy. Please do not need fast response. (2011/07/13 11:35), David E. Wheeler wrote: On Jul 12, 2011, at 5:07 PM, Tom Lane wrote: Curious considering that the machine is there (responds to ping), and the ossp.org webserver works fine. Has anyone bugged the owner about that? I've sent him email and Twitter DMs, to no avail. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL Core Team
Congratulations!! (2011/04/28 3:48), Dave Page wrote: I'm pleased to announce that effective immediately, Magnus Hagander will be joining the PostgreSQL Core Team. Magnus has been a contributor to PostgreSQL for over 12 years, and played a major part in the development and ongoing maintenance of the native Windows port, quickly becoming a committer to help with his efforts. He's one of the project's webmasters and sysadmins and also contributes to related projects such as pgAdmin. In his spare time, he serves as President of the Board of PostgreSQL Europe. Regards, Dave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] OSSP gone missing? Fate of UUID?
Ooops, It is some trobles now. please see Ralf-san's comment. On 01.03.11 15:49, Hiroshi Saito wrote: Hi Ralf-san. Thomas-san. Um... cannot be accessed here. http://www.ossp.org/pkg/lib/uuid/ Are some you in a trouble? The server went down. Thanks for the hint. Now fixed. Ralf S. Engelschall r...@engelschall.com www.engelschall.com Best regards, Hiroshi Saito On Mon, Feb 28, 2011 at 4:08 PM, Michael Glaesemann g...@seespotcode.net wrote: A couple of weeks ago when installing uuid-ossp on a new server, I noticed that the ossp site is gone. I haven't found anything on the web to indicate what happened. Anyone know? Maybe it's time to provide our own UUID generator. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Foreign Visual Studio builds
Hi. Ahh, as for Japanese, it becomes the same. C:\MinGW\home\HIROSHIvcbuild /? Microsoft(R) Visual C++ Project Builder - コマンド ライン バージョン 9.00.21022 Copyright (C) Microsoft Corporation. All rights reserved. http://winpg.jp/~saito/pg_work/VisualStudio/vcbuild_help_SJIS.txt Regards, Hiroshi Saito - Original Message - From: Magnus Hagander mag...@hagander.net On Thu, Oct 14, 2010 at 19:37, Greg Smith g...@2ndquadrant.com wrote: We got an interesting documentation document left by Christian Freund recently, in regards to http://www.postgresql.org/docs/9.0/interactive/install-windows-full.html ; it says: Regarding 16.1.3 - perl mkvcbuild.pl In case you use a German version of VC change line 69 in Solution.pm to: if ($line !~ /^Microsoft\s*\(R\) Visual C\+\+-Projekt-Generator - \D+(\d+)\.00\.\d+/) I'm going to approve the doc comment so that it might help someone else that runs into this in the short-term, but I thought it was was worth sharing as something that might be improved in the build code instead. That regex seems a bit too specific. yeah. I wonder if we can't just get away with: if ($line !~ /^Microsoft\s*\(R\) Visual C\+\+ [^-]+ - \D+(\d+)\.00\.\d+/) That's still quite specific, but should work as long as they don't localize the product name itself. I doubt they do that even in Japanese/Chinese - Hiroshi (or someone else with a Japanese install), can you confirm what the output from vcbuild /? is on a Japanese machine? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] UUIDs generated using ossp-uuid on windows not unique
Hi MUHAMMAD-san. Sorry late reaction... unfortunately, My machine crashed and was not revitalized.:-( However, There is a thing of now a few. http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/ I have a comment from Ralf S. Engelschall. == Sorry for being late with the release of OSSP uuid 2.0.0. Yes, it will be released the next days and will contain the Win32 support I already prepared a few months ago. == It seems that however, he is very busy. ... Regards, Hiroshi Saito - Original Message - From: MUHAMMAD ASIF anaeem...@hotmail.com On Tue, Jun 17, 2008 at 11:17 AM, Hiroshi Saito z-saito(at)guitar(dot)ocn(dot)ne(dot)jp wrote: Hi. Please this. http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/ Ahh, a makefile - that makes things somewhat clearer :-) Thanks - I've updated the build machine so future releases will include this fix. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com It seems that link http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/ is no longer available. I am working on uuid-ossp contrib module, I want to share my findings with you.Thanks. I have downloaded uuid-1.6.2.tar.gz from http://www.ossp.org/pkg/lib/uuid/ . It successfully built with MinGW gcc and made libuuid.a, I renamed it to uuid.lib to build uuid-ossp contrib module with visual studio 2005. uuid-ossp give the following linker error with VC2005 i.e. Linking... Creating library Release\uuid-ossp\uuid-ossp.lib and object Release\uuid-ossp\uuid-ossp.exp uuid.lib(uuid_time.o) : error LNK2019: unresolved external symbol ___divdi3 referenced in function _uuid_time_gettimeofday uuid.lib(uuid_time.o) : error LNK2019: unresolved external symbol ___moddi3 referenced in function _uuid_time_gettimeofday uuid.lib(uuid_str.o) : error LNK2019: unresolved external symbol ___umoddi3 referenced in function _fmtint uuid.lib(uuid_str.o) : error LNK2019: unresolved external symbol ___udivdi3 referenced in function _fmtint .\Release\uuid-ossp\uuid-ossp.dll : fatal error LNK1120: 4 unresolved externals MinGW libgcc.a contains these symbols and these routines are not implemented in c ( its assembly code to make it fast ) so I extracted _divdi3.o _moddi3.o _umoddi3.o _udivdi3.o (we can add these additional files to uuid.lib to make build easy) from libgcc.a and link it with uuid-ossp contrib. I have tested generated uuid-ossp contrib it gives the following results that seems fine i.e. edb=# select uuid_generate_v4(); uuid_generate_v4 -- 20ff31ce-77a8-4db6-ac7f-3b55380e46ac (1 row) edb=# edb=# select uuid_generate_v4() edb-# ; uuid_generate_v4 -- e58c46d5-7161-47ec-8006-f905c6b66a1f (1 row) Any thoughts on this ?. Best Regards, Asif Naeem EnterpriseDB Pakistan: http://www.enterprisedb.com _ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969= -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Anyone know if Alvaro is OK?
Hi Alvaro. Ooops, surprised at news now:-( I'm wishing you and your familys is no trouble. However, I look at one relief because your mail has arrived. ! - Original Message - From: Marc G. Fournier scra...@hub.org On Sat, 27 Feb 2010, Alvaro Herrera wrote: Hi. We're out of town right now, and it seems I can't get to my home machine (probably just a loose cable). Our building was shaken badly enough that we'll have a lot of work to do to make it usable again. Our earthquake was 8.3 or 8.8 depending on who you ask, and whatever it really was, it was strong enough to tear down a bunch of buildings. Not on my zone though, fortunately for us. I have several friends on the worst area though :-( Glad to hear you were in a safer zone .. something I've never had to weather so far in my life, and would rather keep it that way ;( Re: the more frequent earthquakes, yeah I was thinking the same today. An actual scientific study would be more useful than idle speculation though ... One comment that one guy at work had about this was along the lines of aftershocks, where there is a ripple effect that radiates out from a big one affecting seemingly unrelated areas ... not sure how much I subscribe to that theory, as one would think that the 'aftershocks' would be less intense then the original, and, so far, 8.3/8.8 sounds *alot* higher then anything I've heard of recently ... My thoughts and prays go out to you and your family ... Marc G. FournierHub.Org Hosting Solutions S.A. scra...@hub.org http://www.hub.org Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test/example does not support win32.
Hi Alvaro-san. Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set complains Thanks! It seems that pg_bench takes the thing same again into consideration. Anyway, If it is called example of end-user code, what is the evasion method of fd_set? Regards, Hiroshi Saito - Original Message - From: Alvaro Herrera alvhe...@commandprompt.com Hiroshi Saito wrote: Hi Tom-san. Um, How do you consider sample which cannot build? I think testlibpq2.c is missing a couple of system includes, sys/types.h and unistd.h (or alternatively select.h); and testlibpq3.c is missing stdint.h. Or so say my (POSIX) manpages anyway. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test/example does not support win32.
Hi Andrew-san. Although this is a standard in windows. *** testlibpq2.c.orig Wed Dec 30 13:19:03 2009 --- testlibpq2.cThu Dec 31 00:52:52 2009 *** *** 24,34 --- 24,39 * * INSERT INTO TBL1 VALUES (10); */ + + #ifdef WIN32 + #include windows.h + #endif #include stdio.h #include stdlib.h #include string.h #include errno.h #include sys/time.h + #include sys/types.h #include libpq-fe.h static void Does this become the standard which you consider? or #IFDEF Isn't it allowed? Regards, Hiroshi Saito - Original Message - From: Andrew Dunstan and...@dunslane.net To: Tom Lane t...@sss.pgh.pa.us Cc: Hiroshi Saito z-sa...@guitar.ocn.ne.jp; Alvaro Herrera alvhe...@commandprompt.com; pgsql-hackers pgsql-hackers@postgresql.org; Bruce Momjian br...@momjian.us Sent: Thursday, December 31, 2009 12:45 AM Subject: Re: [HACKERS] test/example does not support win32. Tom Lane wrote: Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set complains Thanks! It seems that pg_bench takes the thing same again into consideration. Anyway, If it is called example of end-user code, what is the evasion method of fd_set? On reflection I think it's just wrong to expect that the examples will compile out-of-the-box on every platform. The only way that that can possibly happen is if they depend on our configuration infrastructure, which is exactly what I feel they should not depend on. Any client program that has ambitions of portability is going to have its own autoconf stuff, so injecting ours into a piece of sample code is just going to result in headaches. Even including only pg_config.h would be a serious invasion of application namespace. Looking at pgbench, or any other one of our client-side programs, is not relevant to the point here. Those programs *are* supposed to rely on the PG autoconf environment. We can certainly add some more standard #includes to the examples if they're obviously missing some. But that isn't going to get us to a point where they'll compile everywhere without change. That would be all good and well if we didn't already rely on the configure setup. But we do - the Makefile includes src/Makefile.global, which is built by configure. Anyway, let's see how far we can get with including some standard header files. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test/example does not support win32.
Hi Andrew-san. This saves a windows users. I appreciate your suggestion. Thanks! P.S) I often use by the test by nmake at the time of independent creation of libpq. Regards, Hiroshi Saito - Original Message - From: Andrew Dunstan and...@dunslane.net Hiroshi Saito wrote: Hi Andrew-san. Although this is a standard in windows. *** testlibpq2.c.orig Wed Dec 30 13:19:03 2009 --- testlibpq2.cThu Dec 31 00:52:52 2009 *** *** 24,34 --- 24,39 * * INSERT INTO TBL1 VALUES (10); */ + + #ifdef WIN32 + #include windows.h + #endif #include stdio.h #include stdlib.h #include string.h #include errno.h #include sys/time.h + #include sys/types.h #include libpq-fe.h static void Does this become the standard which you consider? or #IFDEF Isn't it allowed? I certainly think we can use ifdefs. This addition seems OK to me at first glance. Does it solve the problem you encountered? cheers andrew examples_win32_patch2 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test/example does not support win32.
Hi Tom-san. Ahh.. It was correction of the test of often... again, the pursued relation was seen, I think that it is good now. Thanks!! Regards, Hiroshi Saito - Original Message - From: Tom Lane t...@sss.pgh.pa.us Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: [ examples_win32_patch2 ] Is the addition of -DFRONTEND actually needed, and if so why? We shouldn't be depending on that in any user-exposed code, I would think. Otherwise I don't have any objection to this version. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers examples_win32_patch3 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] test/example does not support win32.
Hi. test/example does not support win32. Although I posted also in the past, I am slightly persistent. I think whether it also needs correction of a document. == CVS-HEAD on as for MinGW + gcc == testlibpq2.c: In function `main': testlibpq2.c:98: error: `fd_set' undeclared (first use in this function) testlibpq2.c:98: error: (Each undeclared identifier is reported only once testlibpq2.c:98: error: for each function it appears in.) testlibpq2.c:98: error: syntax error before input_mask testlibpq2.c:105: warning: implicit declaration of function `FD_ZERO' testlibpq2.c:105: error: `input_mask' undeclared (first use in this function) testlibpq2.c:106: warning: implicit declaration of function `FD_SET' testlibpq2.c:108: warning: implicit declaration of function `select' make: *** [testlibpq2] Error 1 testlibpq3.c: In function `show_binary_results': testlibpq3.c:82: error: `uint32_t' undeclared (first use in this function) testlibpq3.c:82: error: (Each undeclared identifier is reported only once testlibpq3.c:82: error: for each function it appears in.) testlibpq3.c:82: error: syntax error before ')' token testlibpq3.c: In function `main': testlibpq3.c:115: error: `uint32_t' undeclared (first use in this function) testlibpq3.c:115: error: syntax error before binaryIntVal testlibpq3.c:183: error: `binaryIntVal' undeclared (first use in this function) testlibpq3.c:183: error: syntax error before numeric constant make: *** [testlibpq3] Error 1 Please take into consideration. Regards, Hiroshi Saito examples_win32_patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] test/example does not support win32.
Hi Tom-san. Um, How do you consider sample which cannot build? Regards, Hiroshi Saito - Original Message - From: Tom Lane t...@sss.pgh.pa.us Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: test/example does not support win32. The proposed added #includes seem quite inappropriate. postgres_fe.h is meant for PG-project code, it is not supposed to have to be included by all end-user code. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] forget patch win32.mak.
Hi Magnus. It is a thing left behind.:-) please apply it. Thanks! == libpq.lib(ip.obj) : error LNK2019: 未解決の外部シンボル __imp__wsaio...@36 が関 数 _pg_foreach_ifaddr で参照されました。 libpq.lib(ip.obj) : error LNK2019: 未解決の外部シンボル __imp__wsasock...@24 が 関数 _pg_foreach_ifaddr で参照されました。 == Regards, Hiroshi Saito win32_patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] forget patch win32.mak.
Hi. Only for CVS-HEAD, not need backpatch. I checked REL8_4_STABLE is this. == nmake -f win32.mak ...snip Microsoft (R) Manifest Tool version 5.2.3790.2076 Copyright (c) Microsoft Corporation 2005. All rights reserved. cd ..\.. echo All Win32 parts have been built! All Win32 parts have been built! == Thanks! Regards, Hiroshi Saito - Original Message - From: Magnus Hagander mag...@hagander.net 2009/11/22 Hiroshi Saito z-sa...@guitar.ocn.ne.jp: Hi Magnus. It is a thing left behind.:-) please apply it. Thanks! == libpq.lib(ip.obj) : error LNK2019: 未解決の外部シンボル __imp__wsaio...@36 が関 数 _pg_foreach_ifaddr で参照されました。 libpq.lib(ip.obj) : error LNK2019: 未解決の外部シンボル __imp__wsasock...@24 が 関数 _pg_foreach_ifaddr で参照されました。 == Hi! Is this for HEAD only, or also for backpatching? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem building from source on Windows
Hi. Ooops, I forgot adjustment completely to Ralf-san. Although Ralf-san understood at the time, he demanded to wait very busily sorry. some infomation. this was due to be contained by 1.6.3/4. This is build the MinGW + gcc. http://winpg.jp/~saito/pg_work/OSSP_win32/ as for MS-VC++, http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/ I will try adjustment again. Regards, Hiroshi Saito - Original Message - From: Ms swati chande swat...@yahoo.com Hi, I am trying to build Postgres (8.3.5) from source on Windows XP using Visual Studio 2005 as per the instructions in the PostgreSQL documentation. The problem is that the uuild.lib and uuid.h files are not tracable though I have done the requisite downloads from uuid and ossp link specified in the documentation. Please help. Regards Swati -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unicode string literals versus the world
Hi.
quick test for great patch. !
== SCRIPT ==
set CLIENT_ENCODING to 'UTF-8';
DROP TABLE ucheck CASCADE;
CREATE TABLE ucheck (key VARCHAR(10) PRIMARY KEY, data NCHAR(50));
set STANDARD_CONFORMING_STRINGS to on;
INSERT INTO ucheck VALUES('ucheck1',u'\68ee\9dd7\5916');
SELECT * FROM ucheck;
set CLIENT_ENCODING to 'SHIFTJIS2004';
SELECT * FROM ucheck;
set STANDARD_CONFORMING_STRINGS to off;
INSERT INTO ucheck VALUES('ucheck2',u'\68ee\9dd7\5916');
=== As for psql ===
This should notice the console of Japanese windows-XP about code can't to display.
C:\workpsql
psql (8.4beta1)
help でヘルプを表示します.
HIROSHI=# set CLIENT_ENCODING to 'UTF-8';
SET
HIROSHI=# DROP TABLE ucheck CASCADE;
DROP TABLE
HIROSHI=# CREATE TABLE ucheck (key VARCHAR(10) PRIMARY KEY, data NCHAR(50));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index ucheck_pkey for
table ucheck
CREATE TABLE
HIROSHI=# set STANDARD_CONFORMING_STRINGS to on;
SET
HIROSHI=# INSERT INTO ucheck VALUES('ucheck',u'\68ee\9dd7\5916');
INSERT 0 1
HIROSHI=# SELECT * FROM ucheck;
key | data
+---
ucheck | 譽ョ鮃怜、・
(1 行)
HIROSHI=# set CLIENT_ENCODING to 'SHIFTJIS2004';
SET
HIROSHI=# SELECT * FROM ucheck;
key | data
+---
ucheck | 森・外
(1 行)
HIROSHI=# set STANDARD_CONFORMING_STRINGS to off;
SET
HIROSHI=# INSERT INTO ucheck VALUES('ucheck2',u'\68ee\9dd7\5916');
ERROR: unsafe use of string constant with Unicode escapes
DETAIL: String constants with Unicode escapes cannot be used when standard_conf
orming_strings is off.
=== As for pgAdminIII ===
pgadmin is shown very well.!!:-)
http://winpg.jp/~saito/pg_work/ucheck/jisx0213.png
P.S)
This test obtains the same result by MimerDB.
Regards,
Hiroshi Saito
- Original Message -
From: Tom Lane t...@sss.pgh.pa.us
Peter Eisentraut pete...@gmx.net writes:
On Tuesday 14 April 2009 21:34:51 Peter Eisentraut wrote:
I think we can handle that and the cases Tom presents by erroring out when
the U syntax is used with stdstr off.
Proposed patch for that attached.
I have not been able to think of any security hole in that proposal,
so this patch seems acceptable to me. I wonder though whether any
corresponding change is needed in psql's lexer, and if so how should
it react exactly to the rejection case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Patch for server-side encoding issues
Hi.
- Original Message -
From: Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp
Here is a WIP patch to solve server-side encoding issues.
It includes Solution of the file name problem of copy on windows patch.
http://archives.postgresql.org/message-id/20090413184335.39be.52131...@oss.ntt.co.jp
It could solve the following issues. They are not only in Windows nor
Japan-specific problems. They could also occur if you use databases
with mulitple encodings or database with non-platform-native encoding
even on POSIX platforms.
1 Non-ascii file paths for database that encoding is different from
platform's encoding (that comes from $LANG or Windows codepage),
especially for COPY TO/FROM.
2 Use appropriate encoding for non-text server log (console, syslog
and eventlog). The encoding is the same as 1.
3 Use appropriate encoding for text server log (stderr and csvlog),
especially database cluster has databases with a variety of encoding.
New GUC parameter 'log_encoding' specifies the encoding in server log.
4 (incomplete) Avoid encoding conversion error in printing server log
and messages for client. Instead of error, print '?' if there is no
equivalent character in the target encoding.
For 4, I use PG_TRY and PG_CATCH for now, but it must be a bad manner.
Instead, I'm thinking that convertion procedures will take an optional
argument whether it should raise error or not. However, we need to
modify all of conversion functions to do so.
More research is needed against following situations:
- NLS messages
- Module path for LOAD
- Arguments for system(), including archive_command and restore_command
- Query texts for other database in pg_stat_activity and pg_stat_statements
Comments welcome. Please notify me if I'm missing something.
Although it is redundant, it looks at much help. It is, even if it may not
be welcomed in the country in many single byte areas. Then, they may think
that they are strange. However, I consider helping in the country using
multi-bytes other than Japan. example displayed on below with a server
message is shown. please see,
C:\workinitdb -E UTF-8 --no-locale
データベースシステム内のファイルの所有者はHIROSHIユーザでした。
このユーザがサーバプロセスを所有しなければなりません。
データベースクラスタはロケールCで初期化されます。
デフォルトのテキスト検索設定はenglishに設定されました。
ディレクトリC:/tmp/日本語 dataの権限を設定しています ... ok
サブディレクトリを作成しています ... ok
デフォルトのmax_connectionsを選択しています ... 100
デフォルトの shared_buffers を選択しています ... 32MB
設定ファイルを作成しています ... ok
C:/tmp/日本語 data/base/1にtemplate1データベースを作成しています ... ok
pg_authidを初期化しています ... ok
依存関係を初期化しています ... ok
システムビューを作成しています ... ok
システムオブジェクトの定義をロードしています ... ok
変換を作成しています ... ok
ディレクトリを作成しています ... ok
組み込みオブジェクトに権限を設定しています ... ok
情報スキーマを作成しています ... ok
template1データベースをバキュームしています ... ok
template1からtemplate0へコピーしています ... ok
template1からpostgresへコピーしています ... ok
警告: ローカル接続向けにtrust認証が有効です。
pg_hba.confを編集する、もしくは、次回initdbを実行する時に-Aオプショ
ンを使用することで変更することができます。
成功しました。以下を使用してデータベースサーバを起動することができます。
postmaster -D C:/tmp/日本語 data
または
pg_ctl -D C:/tmp/日本語 data -l logfile start
C:\workpg_ctl start
サーバは起動中です。
C:\workLOG: データベースシステムは2009-04-16 00:24:13 JSTにシャットダウンしま
した
LOG: データベースシステムの接続受付準備が整いました。
LOG: 自動バキュームランチャプロセス
C:\workpsql postgres
psql (8.4beta1)
help でヘルプを表示します.
postgres=# create table 日本語(きー text);
CREATE TABLE
postgres=# insert into 日本語 values('どうかな');
INSERT 0 1
postgres=# copy 日本語 to 'C:/tmp/日本語 data/ニホンゴutf8.txt';
COPY 1
postgres=# delete from 日本語;
DELETE 1
postgres=# copy 日本語 from 'C:/tmp/日本語 data/ニホンゴutf8.txt';
COPY 1
postgres=# select * from 日本語;
きー
--
どうかな
(1 行)
postgres=# select a;
ERROR: 列aは存在しません(文字位置 8)
STATEMENT: select a;
ERROR: 列aは存在しません
LINE 1: select a;
^
postgres=# create database eucdb encoding = 'EUC_JP';
CREATE DATABASE
postgres=# \c eucdb
psql (8.4beta1)
データベース eucdb に接続しました。.
eucdb=# create table 日本語(きー text);
CREATE TABLE
eucdb=# insert into 日本語 values('どうかな');
INSERT 0 1
eucdb=# copy 日本語 to 'C:/tmp/日本語 data/ニホンゴeucjp.txt';
COPY 1
eucdb=# delete from 日本語;
DELETE 1
eucdb=# copy 日本語 from 'C:/tmp/日本語 data/ニホンゴeucjp.txt';
COPY 1
eucdb=# select * from 日本語;
きー
--
どうかな
(1 行)
eucdb=# select a;
ERROR: 列aは存在しません(文字位置 8)
STATEMENT: select a;
ERROR: 列aは存在しません
LINE 1: select a;
^
eucdb=# \q
C:\workpg_ctl stop
LOG: スマートシャットダウン要求を受け取りました
LOG: 自動バキュームランチャを停止しています
サーバ停止処理の完了を待っていますLOG: シャットダウンしています
LOG: データベースシステムはシャットダウンしました
完了
サーバは停止しました
===
Therefore, I vote +1.
Regards,
Hiroshi Saito
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solution of the file name problem of copy on windows.
Hi.
Anyhow, I appreciate discussion.
- Original Message -
From: Tom Lane t...@sss.pgh.pa.us
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Here is a patch to implement GetPlatformEncoding() and convert absolute
file paths from database encoding to platform encoding.
This seems like a fairly significant overhead added to solve a really
minor problem (if it's not minor why has it never come up before?).
I'm also not convinced by any of the details --- why are GetACP and
pg_get_encoding_from_locale the things to look at, and why is fd.c an
appropriate place to hook in? Surely if we need it here, we need it in
places like initdb as well. But really this is much too low a level to
be solving the problem at. If we have to convert path encodings in the
backend, we should be doing it once somewhere around the place where we
identify the value of PGDATA. It should not be necessary to repeat all
this for every file access within the database directory.
Ahh, I think this is a sensitive problem and requires careful handling too.
However, following tests are shown in order to help your understanding.
This is the case which can't be operated if no apply the patch of Itagaki-san.
C:\workset PGDATA=C:\tmp\日本語 data
C:\workset PGPORT=5444
C:\workset PGHOME=C:\MinGW\local\pgsql
C:\workcmd.exe
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\workinitdb -E UTF-8 --no-locale
データベースシステム内のファイルの所有者はHIROSHIユーザでした。
このユーザがサーバプロセスを所有しなければなりません。
データベースクラスタはロケールCで初期化されます。
デフォルトのテキスト検索設定はenglishに設定されました。
ディレクトリC:/tmp/日本語 dataの権限を設定しています ... ok
サブディレクトリを作成しています ... ok
デフォルトのmax_connectionsを選択しています ... 100
デフォルトの shared_buffers を選択しています ... 32MB
設定ファイルを作成しています ... ok
C:/tmp/日本語 data/base/1にtemplate1データベースを作成しています ... ok
pg_authidを初期化しています ... ok
依存関係を初期化しています ... ok
システムビューを作成しています ... ok
システムオブジェクトの定義をロードしています ... ok
変換を作成しています ... ok
ディレクトリを作成しています ... ok
組み込みオブジェクトに権限を設定しています ... ok
情報スキーマを作成しています ... ok
template1データベースをバキュームしています ... ok
template1からtemplate0へコピーしています ... ok
template1からpostgresへコピーしています ... ok
警告: ローカル接続向けにtrust認証が有効です。
pg_hba.confを編集する、もしくは、次回initdbを実行する時に-Aオプショ
ンを使用することで変更することができます。
成功しました。以下を使用してデータベースサーバを起動することができます。
postmaster -D C:/tmp/日本語 data
または
pg_ctl -D C:/tmp/日本語 data -l logfile start
C:\workset PGCLIENTENCODING=SJIS
C:\workpsql postgres
psql (8.4beta1)
help でヘルプを表示します.
postgres=# create table 日本語(きー text);
CREATE TABLE
postgres=# insert into 日本語 values('いれた');
INSERT 0 1
postgres=# copy 日本語 to 'C:/tmp/日本語 data/日本語utf8.txt';
COPY 1
postgres=# delete from 日本語;
DELETE 1
postgres=# copy 日本語 from 'C:/tmp/日本語 data/日本語utf8.txt';
COPY 1
postgres=# select * from 日本語;
きー
いれた
(1 行)
C:\workdir C:\tmp\日本語 data
ドライブ C のボリューム ラベルは SYS です
ボリューム シリアル番号は 1433-2C7C です
C:\tmp\日本語 data のディレクトリ
2009/04/13 23:22DIR .
2009/04/13 23:22DIR ..
2009/04/13 23:18DIR base
2009/04/13 23:19DIR global
2009/04/13 23:17DIR pg_clog
2009/04/13 23:17 3,616 pg_hba.conf
2009/04/13 23:17 1,611 pg_ident.conf
2009/04/13 23:17DIR pg_multixact
2009/04/13 23:23DIR pg_stat_tmp
2009/04/13 23:17DIR pg_subtrans
2009/04/13 23:17DIR pg_tblspc
2009/04/13 23:17DIR pg_twophase
2009/04/13 23:17 4 PG_VERSION
2009/04/13 23:17DIR pg_xlog
2009/04/13 23:1717,112 postgresql.conf
2009/04/13 23:1938 postmaster.opts
2009/04/13 23:1924 postmaster.pid
2009/04/13 23:22 8 日本語utf8.txt
7 個のファイル 22,413 バイト
11 個のディレクトリ 42,780,246,016 バイトの空き領域
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solution of the file name problem of copy on windows.
Hi. - Original Message - From: Hiroshi Inoue in...@tpf.co.jp Tom Lane wrote: Hiroshi Saito z-sa...@guitar.ocn.ne.jp writes: I want to solve one problem before the release of 8.4. However, since it also seems to be the new feature, if not enough for 8.4, you may suggest that it is 8.5. I'm not too clear on what this is really supposed to accomplish, but we are hardly going to put code like that into every single file access in Postgres, which is what seems to be the logical implication. Shouldn't we just tell people to use a database encoding that matches their system environment? Unfortunately (as usual) under Japanese Windows there's no database encoding that matches the system environment. As for the file name in COPY command, there's little meaning to convert it to the server encoding because the file name is irrelevant to the database. Because Windows is Unicode(UTF-16) based, it seems natural to convert the file name to wide characters once. Yes, If server encoding can be chosen by windows, the facilities in good working order. It was not possible though it was regrettable. Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solution of the file name problem of copy on windows.
Hi Itagaki-san. Um, I had a focus in help the problem which is not avoided. I am not sensitive to a problem being avoided depending on usage. However, I will wish to work spontaneously, when it is help much. Regards, Hiroshi Saito - Original Message - From: Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp Hi, Hiroshi Saito z-sa...@guitar.ocn.ne.jp wrote: At this time, a copy file name is UTF-8. It was troubled by handling.:-( Then, I make this proposal patch. I think the problem is not only in Windows but also in all platforms where the database encoding doesn't match their OS's encoding. Instead of Windows specific codes, how about adding GetPlatformEncoding() and convert all of *absolute* paths? It would be performed at the lowest API layer; i.e, BasicOpenFile(). Standard database file accesses with RelFileNode are not affected because is uses *relative* paths. There are some issues: * Is it possible to determine the platform encoding? * The above cannot handle non-ascii path under $PGDATA. Is it acceptable? * In Windows, the native encoding is UTF-16, but we will use SJIS if we take on the above method. Is the limitation acceptable? Comments welcome. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Solution of the file name problem of copy on windows.
Hi Tom-san.
I want to solve one problem before the release of 8.4.
However, since it also seems to be the new feature,
if not enough for 8.4, you may suggest that it is 8.5.
In Japan, the local file name of a server is dealt with by SJIS.
The example present Postgres...
server_encoding = UTF-8
client_encoding = SJIS
At this time, a copy file name is UTF-8. It was troubled by handling.:-(
Then, I make this proposal patch.
regression test
===
All 120 tests passed.
===
as for database is UTF-8.
HIROSHI=# \l
データベース一覧
名前| 所有者 | エンコーディング | Collation | Ctype | アクセス権
---+-+--+---+---+---
--
HIROSHI | HIROSHI | UTF8 | C | C |
eucdb | HIROSHI | EUC_JP | C | C |
HIROSHI=# create table 日本語てすと (きー text);
CREATE TABLE
HIROSHI=# insert into 日本語てすと values('わーい');
INSERT 0 1
HIROSHI=# copy 日本語てすと to 'C:/tmp/日本語UTF8.txt';
COPY 1
HIROSHI=# delete from 日本語てすと;
DELETE 1
HIROSHI=# copy 日本語てすと from 'C:/tmp/日本語UTF8.txt';
COPY 1
HIROSHI=# select * from 日本語てすと;
きー
わーい
(1 行)
as for database is eucjp.
HIROSHI=# \c eucdb
psql (8.4devel)
データベース eucdb に接続しました。.
eucdb=# \d
リレーションの一覧
スキーマ | 名前 | 型 | 所有者
--+--+---+-
public | 日本語てすと | table | HIROSHI
(1 行)
eucdb=# select * from 日本語てすと;
きー
わーい
(1 行)
eucdb=# copy 日本語てすと to 'C:/tmp/日本語eucdb.txt';
COPY 1
eucdb=# delete from 日本語てすと;
DELETE 1
eucdb=# copy 日本語てすと from 'C:/tmp/日本語eucdb.txt';
COPY 1
eucdb=# select * from 日本語てすと;
きー
わーい
(1 行)
C:\tmpdir 日本語*
ドライブ C のボリューム ラベルは SYS です
ボリューム シリアル番号は 1433-2C7C です
C:\tmp のディレクトリ
2009/04/07 13:58 8 日本語eucdb.txt
2009/04/07 13:58 8 日本語utf8.txt
2 個のファイル 16 バイト
It seems that it is very comfortable. !!
What do you think?
Regards,
Hiroshi Saito
copy_patch3
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Redefine _() to dgettext() instead of gettext() so that it uses
Hi. Ummm, I present is not understood by the reason of Japanese. ... Therefore, It was made into the Spanish case. I know that Alvaro-san will understand Spanish well. ==postgresql.conf== lc_messages= 'es' server.log of a patch before and after was applied. Please see it. Regards, Hiroshi Saito - Original Message - From: Hiroshi Saito z-sa...@guitar.ocn.ne.jp Hi Peter-san. I see the problem for being an original domain in plpgsql. It differs from what codeset meant at postmaster by Japanese windows Please see, this look at the problem on which SJIS enters into a message. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/plpgsql/before_plpgsql_server.log This state is the following. == lc_messages=ja server_encoding=utf-8 == Therefore, it needs to be codeset called for an original domain. It is the procedure in which only a server module must correspond. Then, It is solvable by this patch. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/plpgsql/after_plpgsql_server.log Please take this into consideration. Tahnks. Regards, Hiroshi Saito - Original Message - From: Peter Eisentraut pete...@gmx.net Alvaro Herrera wrote: Peter Eisentraut wrote: Log Message: --- Redefine _() to dgettext() instead of gettext() so that it uses the plpgsql text domain, instead of the postgres one (or whatever the default may be). Hmm, so is this needed on all other PLs too? In principle yes. Or call dgettext() explicitly, which is also done in some cases. However, in most cases messages are issued through ereport(), which handles this automatically (which you implemented, I recall). plpgsql_es_before.log Description: Binary data plpgsql_es_after.log Description: Binary data plpgsql_test.sql Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Redefine _() to dgettext()instead of gettext() so that it uses
Hi Alvaro-san. Yeah, It seems that it saves also except pl. then, It also regards me as very good. I tested just now, of course, it is very comfortable. :-) == try == C:\workpsql -e -f plpgsql_test.sql show client_encoding; client_encoding - latin1 (1 row) show server_encoding; server_encoding - UTF8 (1 row) set lc_messages to es; SET show lc_messages; lc_messages - es (1 row) create function func1() returns int as ' begin select a; end; ' language 'plpgsql'; psql:plpgsql_test.sql:10: ERROR: un identificador entre comillas está inconcluso CONTEXT: compilation of PL/pgSQL function func1 near line 2 ==/END Thanks! Regards, Hiroshi Saito - Original Message - From: Alvaro Herrera alvhe...@commandprompt.com Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Understood. In fact, after having a look at this patch and giving it a little refactoring I think it's pretty obvious; right now we're calling bind_textdomain_codeset only for the main domain, and with this patch we also set it for all other domains we use. More generally, should we push the bindtextdomain calls themselves into the new function (and perhaps call it something else than SetDomainCodeSet)? Seems like logically this should be thought of as all one operation, ie, it's not clear to me that it ever makes sense to call bindtextdomain without also worrying about encoding. I'm not sure that can be made to work easily. On the backend itself we call bindtextdomain in set_pglocale_pgservice() which is also used by programs in src/bin/. Shuffling things in there would be more involved than seems worth. As for names, how about pg_bind_textdomain_codeset? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Redefine _() to dgettext() instead of gettext() so that it uses
Hi Peter-san.
I see the problem for being an original domain in plpgsql. It differs from what
codeset meant at postmaster by Japanese windows
Please see, this look at the problem on which SJIS enters into a message.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/plpgsql/before_plpgsql_server.log
This state is the following.
==
lc_messages=ja
server_encoding=utf-8
==
Therefore, it needs to be codeset called for an original domain. It is the
procedure in which
only a server module must correspond. Then, It is solvable by this patch.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/plpgsql/after_plpgsql_server.log
Please take this into consideration.
Tahnks.
Regards,
Hiroshi Saito
- Original Message -
From: Peter Eisentraut pete...@gmx.net
Alvaro Herrera wrote:
Peter Eisentraut wrote:
Log Message:
---
Redefine _() to dgettext() instead of gettext() so that it uses the plpgsql
text domain, instead of the postgres one (or whatever the default may be).
Hmm, so is this needed on all other PLs too?
In principle yes. Or call dgettext() explicitly, which is also done in
some cases. However, in most cases messages are issued through
ereport(), which handles this automatically (which you implemented, I
recall).
*** src/backend/utils/mb/mbutils.c.orig Sun Mar 1 01:46:59 2009
--- src/backend/utils/mb/mbutils.c Sun Mar 1 01:46:48 2009
***
*** 883,888
--- 883,905
#endif /* WIN32 */
void
+ SetDomainCodeSet(const char *domainname)
+ {
+ #if defined(ENABLE_NLS) defined(WIN32)
+ int i;
+ for (i = 0; i sizeof(codeset_map_array) /
sizeof(codeset_map_array[0]); i++)
+ {
+ if (codeset_map_array[i].encoding == GetDatabaseEncoding())
+ {
+ if (bind_textdomain_codeset(domainname,
codeset_map_array[i].codeset) == NULL)
+ elog(LOG, bind_textdomain_codeset failed);
+ break;
+ }
+ }
+ #endif
+ }
+
+ void
SetDatabaseEncoding(int encoding)
{
if (!PG_VALID_BE_ENCODING(encoding))
*** src/include/mb/pg_wchar.h.orig Sun Mar 1 01:49:00 2009
--- src/include/mb/pg_wchar.h Sun Mar 1 01:49:48 2009
***
*** 389,394
--- 389,395
extern int pg_get_client_encoding(void);
extern const char *pg_get_client_encoding_name(void);
+ extern void SetDomainCodeSet(const char *domainname);
extern void SetDatabaseEncoding(int encoding);
extern int GetDatabaseEncoding(void);
extern const char *GetDatabaseEncodingName(void);
*** src/pl/plpgsql/src/pl_handler.c.origSun Mar 1 01:55:34 2009
--- src/pl/plpgsql/src/pl_handler.c Sun Mar 1 01:57:58 2009
***
*** 22,27
--- 22,28
#include utils/guc.h
#include utils/lsyscache.h
#include utils/syscache.h
+ #include mb/pg_wchar.h
PG_MODULE_MAGIC;
***
*** 43,48
--- 44,51
return;
pg_bindtextdomain(TEXTDOMAIN);
+ /* domain codeset */
+ SetDomainCodeSet(TEXTDOMAIN);
plpgsql_HashTableInit();
RegisterXactCallback(plpgsql_xact_cb, NULL);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] regression test crashes at tsearch
Hi Teodor-san. Sorry late reaction. - Original Message - From: Teodor Sigaev teo...@sigaev.ru If there's an effective function like pg_wchar2mb_with_len() which converts wchar_t strings to server encoded strings, we had better simply call it for char2wchar(). I don't see a way to produce correct result of char2wchar with C-locale and sizeof(wchar_t) = 2. In summary, I suggest to remove support of C-locale from char2wchar function and tsearch's parser should directly use pg_mb2wchar_with_len() in case of C-locale and multibyte encoding. In all other places char2wchar is called only for non-C locale. Please, test attached patch. Um, I think your patch like the overkill reaction of C-locale... However, I tried your patch. make check MULTIBYTE=euc_jp NO_LOCALE=true ... === All 120 tests passed. === Anyway, either should be applied. Thanks. Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] regression test crashes at tsearch
Hi. Sorry late reaction. I try check of CVS-HEAD now. $ make check NO_LOCALE=true ... === All 120 tests passed. === However, same action as Inou-sane is seen. make check MULTIBYTE=euc_jp NO_LOCALE=true The differences that caused some tests to fail can be viewed in the file C:/MinGW/home/HIROSHI/pgsql/src/test/regress/regression.diffs. A copy of the test summary that you see above is saved in the file C:/MinGW/home/HIROSHI/pgsql/src/test/regress/regression.out. make[2]: *** [check] Error 1 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 http://winpg.jp/~saito/pg_bug/20090223-CVS-regression.diffs http://winpg.jp/~saito/pg_bug/20090223-CVS-regression.out Then, It is comfortable after applying Inoue-san patch. make check MULTIBYTE=euc_jp NO_LOCALE=true ... === All 120 tests passed. === I think that Mr. Inoue's patch is right. why isn't it taken into consideration yet? Regards, Hiroshi Saito - Original Message - From: Hiroshi Inoue in...@tpf.co.jp Hi, I see a regression test failure in my mingw-vista port when I invoke the command make check MULTIBYTE=euc_jp NO_LOCALE=yes . It causes a crash at tsearch. The crash seems to occur when the server encoding isn't UTF-8 with no locale. The attached is a patch to avoid the crash. regards, Hiroshi Inoue -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgevent warnings on mingw
- Original Message - From: Magnus Hagander mag...@hagander.net Hiroshi Saito wrote: Ahh, sorry..like the spam again! I thought over that the existing msvc the did not have uneasines. so, I wish to make it this as correspondence with worried Magnus-san. It is after sufficient test. If I read this patch right, it does an export all symbols when run on mingw? That surely can't be right? We may not have any additional symbols there now, but it's certaily not the intention? Plus, it makes msvc behave differently from mingw (since msvc uses the exports.txt)? I did some more checking, and it seems MS has changed the warnings in the new version of VIsual Studio. Right now, the following exports.txt file passes without warnings. Can someone check if it does on mingw? EXPORTS DllUnregisterServer @ 1; DllRegisterServer @ 2; Do you need all that extra decoration junk on mingw, or does it work this way? It was checked. $ cat pgevent.def EXPORTS DllUnregisterServer @ 1; DllRegisterServer @ 2; $ make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -I../../../src/include -I/C/work/MinGW_WORK/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../../src/include/port/win32 -c -o pgevent.o pgevent.c sed -e 's;FILEDESC;Eventlog message formatter;' -e 's;VFT_APP;VFT_DLL;' -e 's;_ICO_;;' -e 's;\(VERSION.*\),0 *$;\1,'`date '+%y%j' | sed 's/^0*//'`';' ../../../src/port/win32ver.rc win32ver.rc windres pgmsgevent.rc -o pgmsgevent.o --include-dir=../../../src/include --include-dir=../../../src/include --include-dir=. dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o Warning: resolving _DllUnregisterServer by linking to _dllunregisterser...@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _dllregisterser...@0 Warning: resolving _DllUnregisterServer by linking to _dllunregisterser...@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _dllregisterser...@0 Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgevent warnings on mingw
Hi. dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o Warning: resolving _DllUnregisterServer by linking to _dllunregisterser...@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _dllregisterser...@0 Warning: resolving _DllUnregisterServer by linking to _dllunregisterser...@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _dllregisterser...@0 What do we have to do to clean this stuff up? I was solved for Marko-san at the time of the work of pgbouncer, and obtained the solution. The patch is this. == Before == $ make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -I../../../src/include -I/C/work/MinGW_WORK/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../../src/include/port/win32 -c -o pgevent.o pgevent.c sed -e 's;FILEDESC;Eventlog message formatter;' -e 's;VFT_APP;VFT_DLL;' -e 's;_ICO_;;' -e 's;\(VERSION.*\),0 *$;\1,'`date '+%y%j' | sed 's/^0*//'`';' ../../../src/port/win32ver.rc win32ver.rc windres pgmsgevent.rc -o pgmsgevent.o --include-dir=../../../src/include --include-dir=../../../src/include --include-dir=. dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o Warning: resolving _DllUnregisterServer by linking to _dllunregisterser...@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _dllregisterser...@0 Warning: resolving _DllUnregisterServer by linking to _dllunregisterser...@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _dllregisterser...@0 == After patch. == $ make gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g -I../../../src/include -I/C/work/MinGW_WORK/include -I./src/include/port/win32 -DEXEC_BACKEND -I../../../src/include/port/win32 -c -o pgevent.o pgevent.c sed -e 's;FILEDESC;Eventlog message formatter;' -e 's;VFT_APP;VFT_DLL;' -e 's;_ICO_;;' -e 's;\(VERSION.*\),0 *$;\1,'`date '+%y%j' | sed 's/^0*//'`';' ../../../src/port/win32ver.rc win32ver.rc windres pgmsgevent.rc -o pgmsgevent.o --include-dir=../../../src/include --include-dir=../../../src/include --include-dir=. dlltool --export-all-symbols -A --output-def pgevent.def pgevent.o pgmsgevent.o dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o == It will be great if this is taken into consideration. Regards, Hiroshi Saito pgevent_patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgevent warnings on mingw
Hi. Sorry, I was not able to find the point to which you point. This appears to be exactly what you are *not* supposed to do. Which is assign an ordinal. See: http://msdn.microsoft.com/en-us/library/8e705t74(VS.71).aspx (that's just about the warning, there is a page somewhere with more details, but I can't find it right now) Please see this, if the point which you suggest becomes about output image size. == Before == -rwxr-xr-x1 HIROSHI Administ 425977 Feb 1 00:33 pgevent.dll == After patch. == -rwxr-xr-x1 HIROSHI Administ 425955 Feb 1 00:34 pgevent.dll Then, new pgevent.def is this. ; C:\MinGW\bin\dlltool.exe --export-all-symbols -A --output-def pgevent.def pgevent.o pgmsgevent.o EXPORTS dllregisterser...@0 @ 1 DllUnregisterServer = dllunregisterser...@0 @ 2 dllunregisterser...@0 @ 3 g_module @ 4 DATA DllRegisterServer = dllregisterser...@0 @ 5 Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] mingw check hung
Hi. Well, XP only does it when it's built with mingw! Or is this actually dependent on if the binary is run under msys or cmd? Both they look at a problem. http://winpg.jp/~saito/pg_bug/20090124/ Then, If SetEnvironmentVariable of Andrew-san point is removed, a problem will clearvery strange... Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgevent warnings on mingw
Hi. I am checking that consider sufficient test as Marko-san and it is satisfactory. However, That there is a portion which does not suit the solution of MSVC also understands. Therefore, How is this proposal? 1. )remove pgevent.def It is always generated. 2.) improvement of the Makefile and Solution.pm What do you think? Regards, Hiroshi Saito - Original Message - From: Marko Kreen mark...@gmail.com On 1/31/09, Marko Kreen mark...@gmail.com wrote: On 1/31/09, Magnus Hagander mag...@hagander.net wrote: Hiroshi Saito wrote: Hi. dllwrap --def pgevent.def -o pgevent.dll pgevent.o pgmsgevent.o Warning: resolving _DllUnregisterServer by linking to _dllunregisterser...@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _dllregisterser...@0 Warning: resolving _DllUnregisterServer by linking to _dllunregisterser...@0 Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups Warning: resolving _DllRegisterServer by linking to _dllregisterser...@0 What do we have to do to clean this stuff up? I was solved for Marko-san at the time of the work of pgbouncer, and obtained the solution. The patch is this. This appears to be exactly what you are *not* supposed to do. Which is assign an ordinal. See: http://msdn.microsoft.com/en-us/library/8e705t74(VS.71).aspx AFAICS by default the mingw assigns the ordinal anyway? So whats your point? FWIW, I experimented with various approaches on DLL generation, and my theory is now that numeric slot is mandatory for export, name slot optional. And what the above link above warns about is that if you manually assign a numeric slot, you may create gaps in slot table, thus resulting in larger image. But this assumes you already have slots that are manually assigned, which should not happen with pgevent.dll. Does it sound sane? With pgbouncer I used dlltool --export-all-symbols -A to generate the .def file, thus the slots are actually assigned automatically by dlltool, so no gap problems should arise. As Postgres does not generate .def automatically, thus Hiroshi simply posted the resulting .def file, which should not have gap problems. But such detailed .def avoids the confusing warnings from dllwrap. If you are worried about gap problems I suggest instead doing the same and making the .def file auto-generated. -- marko ps. I suggest also tagging the g_module as static. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers pgevent_def_patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgevent warnings on mingw
Ooops, sorry., One mistake:-( Please this. - Original Message - From: Hiroshi Saito z-sa...@guitar.ocn.ne.jp Hi. I am checking that consider sufficient test as Marko-san and it is satisfactory. However, That there is a portion which does not suit the solution of MSVC also understands. Therefore, How is this proposal? 1. )remove pgevent.def It is always generated. 2.) improvement of the Makefile and Solution.pm What do you think? Regards, Hiroshi Saito pgevent_def_patch_v2 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgevent warnings on mingw
Ahh, sorry..like the spam again! I thought over that the existing msvc the did not have uneasines. so, I wish to make it this as correspondence with worried Magnus-san. It is after sufficient test. Regards, Hiroshi Saito - Original Message - From: Hiroshi Saito z-sa...@guitar.ocn.ne.jp Ooops, sorry., One mistake:-( Please this. - Original Message - From: Hiroshi Saito z-sa...@guitar.ocn.ne.jp Hi. I am checking that consider sufficient test as Marko-san and it is satisfactory. However, That there is a portion which does not suit the solution of MSVC also understands. Therefore, How is this proposal? 1. )remove pgevent.def It is always generated. 2.) improvement of the Makefile and Solution.pm What do you think? Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers pgevent_def_patch_v3 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solve a problem of LC_TIME of windows.
Ops,my mistake in the mail thread.:-( sorry. === send the mistake other thread == Hi. My swift attack test was the MinGW environment. But, Inoue-san suggestion. 1. MinGW+gcc build HIROSHI=# set LC_TIME=Ja; SET HIROSHI=# select to_char(now(),'TMDay'); to_char - 日曜日 (1 行) HIROSHI=# set LC_TIME='Japan'; SET HIROSHI=# select to_char(Now(),'TMDay'); to_char - 日曜日 (1 行) HIROSHI=# set LC_TIME='Japanese'; SET HIROSHI=# select to_char(Now(),'TMDay'); to_char - 日曜日 (1 行) However, A setup of 'Ja' was strange.?_? http://msdn.microsoft.com/en-us/library/aa246450(VS.60).aspx 2. MSVC build HIROSHI=# set LC_TIME='Ja'; ERROR: invalid value for parameter lc_time: Ja STATEMENT: set LC_TIME='Ja'; ERROR: invalid value for parameter lc_time: Ja HIROSHI=# set LC_TIME='Japan'; ERROR: invalid value for parameter lc_time: Japan STATEMENT: set LC_TIME='Japan'; ERROR: invalid value for parameter lc_time: Japan HIROSHI=# set LC_TIME=Japanese; SET HIROSHI=# select to_char(Now(),'TMDay'); to_char - 日曜日 (1 行) Umm, Re-investigation is required for this. :-( However, If reasonable clear, it will be good for a document at suggestion. Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Explicitly bind gettext() to the UTF8 locale when in use.
Hi. My swift attack test was the MinGW environment. But, Inoue-san suggestion. 1. MinGW+gcc build HIROSHI=# set LC_TIME=Ja; SET HIROSHI=# select to_char(now(),'TMDay'); to_char - 日曜日 (1 行) HIROSHI=# set LC_TIME='Japan'; SET HIROSHI=# select to_char(Now(),'TMDay'); to_char - 日曜日 (1 行) HIROSHI=# set LC_TIME='Japanese'; SET HIROSHI=# select to_char(Now(),'TMDay'); to_char - 日曜日 (1 行) However, A setup of 'Ja' was strange.?_? http://msdn.microsoft.com/en-us/library/aa246450(VS.60).aspx 2. MSVC build HIROSHI=# set LC_TIME='Ja'; ERROR: invalid value for parameter lc_time: Ja STATEMENT: set LC_TIME='Ja'; ERROR: invalid value for parameter lc_time: Ja HIROSHI=# set LC_TIME='Japan'; ERROR: invalid value for parameter lc_time: Japan STATEMENT: set LC_TIME='Japan'; ERROR: invalid value for parameter lc_time: Japan HIROSHI=# set LC_TIME=Japanese; SET HIROSHI=# select to_char(Now(),'TMDay'); to_char - 日曜日 (1 行) Umm, Re-investigation is required for this. :-( However, If reasonable clear, it will be good for a document at suggestion. Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solve a problem of LC_TIME of windows.
Hi. Thanks all. I tried CVS-HEAD now. HIROSHI=# select to_char(now(),'TMDay'); to_char -- Saturday (1 行) HIROSHI=# set LC_MESSAGES=Ja; SET HIROSHI=# select to_char(now(),'TMDay'); to_char -- Saturday (1 行) Umm, It does not look at a comfortable result.:-( I will check it on tomorrow night. sorry busy now.. Regards, Hiroshi Saito - Original Message - From: Magnus Hagander mag...@hagander.net ITAGAKI Takahiro wrote: Hiroshi Inoue in...@tpf.co.jp wrote: Seems LC_CTYPE and LC_TIME should be convertible even though we use wcsftime (which internally calls strftime?). Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting (at least encoding) on Windows. The attached patch is an updated version to fix cache_locale_time(). Now it sets LC_TIME and LC_CTYPE to the specified locale and restore them at end of the function. I tested the patch on Windows XP Japanese Edition (SJIS) with UTF-8 and EUCJP databases, and worked expectedly. #ifdef WIN32 codes seems to be ugly in the patch, but I have no other idea... I have applied this version of the patch (with only a minor further addition to the comment). Thank you all for your work and patience in getting this fixed! Let's hope it stays fixed :-) //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solve a problem of LC_TIME of windows.
I thought this was supposed to be driven by LC_TIME now, not LC_MESSAGES. Uga, yes yes! HIROSHI=# set LC_TIME=Ja; SET HIROSHI=# select to_char(now(),'TMDay'); to_char - 土曜日 (1 行) Thanks:-) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Solve a problem of LC_TIME of windows.
I've also thought a similar implementation but there seems a problem of efficiency. As far as I see wcsftime() is almost = strftime() + mbstowcs() and so using strftime() is effective at least for the following cases. 1) LC_CTIME is C. 2) LC_CTYPE != C and the database encoding != UTF-8. In this case the current restriction of PostgreSQL requires that the database encoding matches the encoding of the LC_CTYPE. We seem to be able to call strftime() directly in above cases. Comments ? I quite agree on that point. == 遅くまですみません、、もう寝ましょう:-) Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4186: set lc_messages does not work
Hi. Sorry very late reaction I report the test checked again. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/LC_MESSAGES_01.png http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/LC_MESSAGES_02.png http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/LC_MESSAGES_03.png http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/LC_MESSAGES_04.png and http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/LC_MESSAGES.sql Then, set PGCLIENTENCODING=SJIS http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/LC_MESSAGES.log However, libintl needs to be created correctly.(Inoue-san prepares this.) http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/bin/ http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/include/ http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/lib/ in CVS-HEAD of the newest patch, line positions differ for a while.(.Inoue-san prepares this.) http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/mbutils_2.patch http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/libintl_check/win_lc_messages_2.patch Conclusion, looks at a good result.!! Regards, Hiroshi Saito - Original Message - From: Hiroshi Inoue in...@tpf.co.jp Oops, I forgot to attach the patch, sorry. Hiroshi Inoue wrote: Hi, I posted a patch 18 days ago but have got no responce. Anyway I've simplified the patch by using an appropriate gettext module. Hiroshi Inoue wrote: Bruce Momjian wrote: Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: Thomas H. wrote: so at least that explains the changed behaviour. nevertheless, LC_MESSAGES seems to be defunct - with the locale folder present, pg always picks the os' language and ignores the lc_message value. This looks like I can reproduce though, at least on cvs head. Did this work for you in previous versions? Maybe we were using a different build of gettext in the previous releases, one that didn't look at the same info as the current code? Where are we on this? AFAICS there are 2 causes. 1. MSVC version of postgres is using a bad gettext module. 2. getenv() in mingw cannot see the result of putenv() in MSVC8.0. As for 1, we have to use another gettext module. I can provide it if requested. As for 2, pg_putenv() or pg_unsetenv() in the attachced patch calls corresponding putenv() whose result can be referenced by getenv() in mingw. In addtion the patch provides a functionality to Windows locale name to ISO formatted locale name. Comments ? regards, Hiroshi Inoue -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Solve a problem of LC_TIME of windows.
Hi ITAGAKI-san. Um, It was not supported. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt The test of my various past is reproduced. Then, I proposed the management regarded as best in them. and, to Magnus-san. Does the reason for persisting in wsftime exceed a safe reason? However, I may have missed something... Regards, Hiroshi Saito - Original Message - From: ITAGAKI Takahiro [EMAIL PROTECTED] Hiroshi Saito [EMAIL PROTECTED] wrote: Umm, format operand seems to be a wide character sequence. Here is a patch to work around the wide character format string. The hack is the following line: +#define strftime(a,b,c,d) strftime_win32(a,b,L##c,d) We use only literals in the format strings, the macro adds wide character prefix (L...) to them. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Solve a problem of LC_TIME of windows.
Hi. I think that MinGW does not have a direct relation. #define_UNICODE is required for wcsftime. Probably, ITAGAKI-san has only forgotten it.:-) P.S) 日本語になっていましたです:-) Regards, Hiroshi Saito - Original Message - From: Hiroshi Inoue [EMAIL PROTECTED] 井上です。 ITAGAKI Takahiro wrote: Hiroshi Saito [EMAIL PROTECTED] wrote: Um, It was not supported. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt Hmm... the implementation of wcsftime() in msvcrt seems to be completely broken. I ran the attached test (localetest.c) and got the following results. The point is that wcsftime() returns the same character codes as strftime() i.e, the result is not an unicode string :-( The bug might be fixed in recently msvcrts in VC2005 or VC2008, but at least mingw uses the old broken C runtime. 私はmingwを使っていないのでよくわからないのですが、ランタイムも一緒に 提供しているのですか？ We'd better to use strftime() and multiple conversions to avoid the Microsoft's bug. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Solve a problem of LC_TIME of windows.
Hi Magnus-san.
Um, Though regrettable, it is not in a good state.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/Mugnus-patch.png
- Original Message -
From: Magnus Hagander [EMAIL PROTECTED]
The way I read this patch we do:
1) Get the time in CP_ACP
2) Convert to UTF16
3) Convert to UTF8
4) If necessary, convert to the charset in the database
We could be more efficient by at least folding 1 and 2 into a single
step, which means getting it in UTF16 from the beginning. How about
attached patch? It builds, but please verify that it fixes the problem.
(I've updated the comment as well)
Attached pg_locale_utf16.patch. I'm also attaching
pg_locale_diffdiff.patch which contains the changes I've made against
your patch only.
//Magnus
Hiroshi Saito wrote:
Hi.
All suggestion is appropriate and has been checked.
CVS-HEAD was examined by MinGW. $ make check NO_LOCALE=true
...
===
All 118 tests passed. ===
Then, It continues and a review is desired. Thanks!
Regatrds,
Hiroshi Saito
- Original Message - From: Hiroshi Saito
[EMAIL PROTECTED]
Hi ITAGAKI-san.
Sorry, very late reaction..
I lost time resources in an individual my machine trouble and
busyness.:-(
Now, I appreciate your exact work. ! Then, I desire the best patch for
PostgreSQL. Probably, I think that it is finally helpful in not a
problem of only Japan but many countries. Tom-san, and Alvaro-san,
Magnus-san understands the essence of this problem. Therefore, the
suggestion is expected for me.
Anyway, thank you very much.!!
Regards,
Hiroshi Saito
- Original Message - From: ITAGAKI Takahiro
[EMAIL PROTECTED]
Jaime Casanova [EMAIL PROTECTED] wrote:
i'm confused, original patch has this signature:
+ conv_strftime(char *src, size_t len, const char *format, const
struct tm *tm)
your's has:
+strftime_win32(char *dst, size_t dstlen, const char *format, const
you change all src for dst, just a variable name decision but a
radical one... why was that (i honestly doesn't understand this patch
very well ;)?
That's because the first argument is not an input buffer,
but an output buffer. MSDN also calls it 'strDest'.
http://msdn.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx
Linux manpage calls it 's', but I think it means String, not Src.
http://man.cx/strftime
If you can review the patch, please use the attached one instead.
I modified it in response to the discussion of
pg_do_encoding_conversion.
BTW, I cannot understand the comment in the function head,
+ * result is obtained by locale setup of LC_TIME in the environment
+ * of windows at present CP_ACP. Therefore, conversion is needed
+ * for SERVER_ENCODING. SJIS which is not especially made to server
+ * encoding in Japan returns.
but it probably says:
strftime in Windows returns in CP_ACP encoding, but it could be
different from SERVER_ENCODING. Especially, Windows Japanese edition
requires conversions because it uses SJIS as CP_ACP, but we don't
support SJIS as a server encoding.
I hope you would review my English not only C ;-)
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 54,59
--- 54,60
#include utils/memutils.h
#include utils/pg_locale.h
+ #include mb/pg_wchar.h
#define MAX_L10N_DATA 80
***
*** 452,457 PGLC_localeconv(void)
--- 453,507
return CurrentLocaleConv;
}
+ #ifdef WIN32
+ /*
+ * On win32, strftime() returns the encoding in CP_ACP, which is likely
+ * different from SERVER_ENCODING. This is especially important in Japanese
+ * versions of Windows which will use SJIS encoding, which we don't support
+ * as a server encoding.
+ *
+ * Replace strftime() with a version that gets the string in UTF16 and then
+ * converts it to the appropriate encoding as necessary.
+ */
+ static size_t
+ strftime_win32(char *dst, size_t dstlen, const char *format, const struct tm
*tm)
+ {
+ size_t len;
+ wchar_t wbuf[MAX_L10N_DATA];
+ int encoding;
+
+ encoding = GetDatabaseEncoding();
+ if (encoding == PG_SQL_ASCII)
+ return len;
+
+ len = wcsftime(wbuf, sizeof(wbuf), format, tm);
+ if (len == 0)
+ /* strftime called failed - return 0 with the contents of dst unspecified */
+ return 0;
+
+ len = WideCharToMultiByte(CP_UTF8, 0, wbuf, len, dst, dstlen, NULL, NULL);
+ if (len == 0)
+ ereport(ERROR,
+ (errmsg(could not convert string to UTF-8:error %lu, GetLastError(;
+
+ dst[len] = '\0';
+ if (encoding != PG_UTF8)
+ {
+ char *convstr = pg_do_encoding_conversion(dst, len, PG_UTF8, encoding);
+ if (dst != convstr)
+ {
+ StrNCpy(dst, convstr, dstlen);
+ len = strlen(dst
Re: [HACKERS] [PATCHES] Solve a problem of LC_TIME of windows.
Hi Magnus-san.
Umm, format operand seems to be a wide character sequence.
- Original Message -
From: Magnus Hagander [EMAIL PROTECTED]
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 54,59
--- 54,60
#include utils/memutils.h
#include utils/pg_locale.h
+ #include mb/pg_wchar.h
#define MAX_L10N_DATA 80
Please stick to the convention of including include files in
alphabetical order.
Check.
+ strftime_win32(char *dst, size_t dstlen, const char *format, const struct tm
*tm)
+ {
+ size_t len;
+ wchar_t wbuf[MAX_L10N_DATA];
+ int encoding;
+
+ encoding = GetDatabaseEncoding();
+ if (encoding == PG_SQL_ASCII)
+ return len;
Surely this is returning an uninitialized variable, not to mention
failing to accomplish any of the goals of the function. I don't think
breaking things completely for SQL_ASCII was part of the plan.
Gah, true, that's me breaking it. That was correct in Hiroshi-san's
patch. My bad, sorry.
+ ereport(ERROR,
+ (errmsg(could not convert string to UTF-8:error %lu, GetLastError(;
This is not exactly per message style guidelines. Maybe it's just a
can't-happen case, but if so make it elog not ereport.
Check.
Forgot the attachment.
//Magnus
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/utils/adt/pg_locale.c
***
*** 51,56
--- 51,57
#include time.h
#include catalog/pg_control.h
+ #include mb/pg_wchar.h
#include utils/memutils.h
#include utils/pg_locale.h
***
*** 452,457 PGLC_localeconv(void)
--- 453,507
return CurrentLocaleConv;
}
+ #ifdef WIN32
+ /*
+ * On win32, strftime() returns the encoding in CP_ACP, which is likely
+ * different from SERVER_ENCODING. This is especially important in Japanese
+ * versions of Windows which will use SJIS encoding, which we don't support
+ * as a server encoding.
+ *
+ * Replace strftime() with a version that gets the string in UTF16 and then
+ * converts it to the appropriate encoding as necessary.
+ */
+ static size_t
+ strftime_win32(char *dst, size_t dstlen, const char *format, const struct tm
*tm)
+ {
+ size_t len;
+ wchar_t wbuf[MAX_L10N_DATA];
+ int encoding;
+
+ encoding = GetDatabaseEncoding();
+ if (encoding == PG_SQL_ASCII)
+ return strftime(dst, dstlen, format, tm);
+
+ len = wcsftime(wbuf, sizeof(wbuf), format, tm);
+ if (len == 0)
+ /* strftime call failed - return 0 with the contents of dst unspecified */
+ return 0;
+
+ len = WideCharToMultiByte(CP_UTF8, 0, wbuf, len, dst, dstlen, NULL, NULL);
+ if (len == 0)
+ elog(ERROR,
+ could not convert string to UTF-8:error %lu, GetLastError());
+
+ dst[len] = '\0';
+ if (encoding != PG_UTF8)
+ {
+ char *convstr = pg_do_encoding_conversion(dst, len, PG_UTF8, encoding);
+ if (dst != convstr)
+ {
+ StrNCpy(dst, convstr, dstlen);
+ len = strlen(dst);
+ }
+ }
+
+ return len;
+ }
+
+ #define strftime(a,b,c,d) strftime_win32(a,b,c,d)
+
+ #endif /* WIN32 */
+
/*
* Update the lc_time localization cache variables if needed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Solve a problem of LC_TIME of windows.
Hi Jaime-san.
Thank you for a review.
I think this purpose to return the value which should originally obtain strftime
by only replacing here. Then, I think that it is a superfluous reaction.
However, some consideration may be necessities.
Regards,
Hiroshi Saito
- Original Message -
From: Jaime Casanova [EMAIL PROTECTED]
On Sun, Nov 16, 2008 at 8:36 AM, Hiroshi Saito [EMAIL PROTECTED] wrote:
Hi.
Then, It continues and a review is desired. Thanks!
In http://msdn.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx says:
Return Value
strftime returns the number of characters placed in strDest and
wcsftime returns the corresponding number of wide characters.
If the total number of characters, including the terminating null, is
more than maxsize, both strftime and wcsftime return 0 and the
contents of strDest is indeterminate.
If i'm reading it right, the patch should contain something like:
if (len dstlen)
{
return 0;
}
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Solve a problem of LC_TIME of windows.
Hi. All suggestion is appropriate and has been checked. CVS-HEAD was examined by MinGW. $ make check NO_LOCALE=true ... === All 118 tests passed. === Then, It continues and a review is desired. Thanks! Regatrds, Hiroshi Saito - Original Message - From: Hiroshi Saito [EMAIL PROTECTED] Hi ITAGAKI-san. Sorry, very late reaction.. I lost time resources in an individual my machine trouble and busyness.:-( Now, I appreciate your exact work. ! Then, I desire the best patch for PostgreSQL. Probably, I think that it is finally helpful in not a problem of only Japan but many countries. Tom-san, and Alvaro-san, Magnus-san understands the essence of this problem. Therefore, the suggestion is expected for me. Anyway, thank you very much.!! Regards, Hiroshi Saito - Original Message - From: ITAGAKI Takahiro [EMAIL PROTECTED] Jaime Casanova [EMAIL PROTECTED] wrote: i'm confused, original patch has this signature: + conv_strftime(char *src, size_t len, const char *format, const struct tm *tm) your's has: +strftime_win32(char *dst, size_t dstlen, const char *format, const you change all src for dst, just a variable name decision but a radical one... why was that (i honestly doesn't understand this patch very well ;)? That's because the first argument is not an input buffer, but an output buffer. MSDN also calls it 'strDest'. http://msdn.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx Linux manpage calls it 's', but I think it means String, not Src. http://man.cx/strftime If you can review the patch, please use the attached one instead. I modified it in response to the discussion of pg_do_encoding_conversion. BTW, I cannot understand the comment in the function head, + * result is obtained by locale setup of LC_TIME in the environment + * of windows at present CP_ACP. Therefore, conversion is needed + * for SERVER_ENCODING. SJIS which is not especially made to server + * encoding in Japan returns. but it probably says: strftime in Windows returns in CP_ACP encoding, but it could be different from SERVER_ENCODING. Especially, Windows Japanese edition requires conversions because it uses SJIS as CP_ACP, but we don't support SJIS as a server encoding. I hope you would review my English not only C ;-) Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers pg_locale_patch-v5 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Solve a problem of LC_TIME of windows.
Hi ITAGAKI-san. Sorry, very late reaction.. I lost time resources in an individual my machine trouble and busyness.:-( Now, I appreciate your exact work. ! Then, I desire the best patch for PostgreSQL. Probably, I think that it is finally helpful in not a problem of only Japan but many countries. Tom-san, and Alvaro-san, Magnus-san understands the essence of this problem. Therefore, the suggestion is expected for me. Anyway, thank you very much.!! Regards, Hiroshi Saito - Original Message - From: ITAGAKI Takahiro [EMAIL PROTECTED] Jaime Casanova [EMAIL PROTECTED] wrote: i'm confused, original patch has this signature: + conv_strftime(char *src, size_t len, const char *format, const struct tm *tm) your's has: +strftime_win32(char *dst, size_t dstlen, const char *format, const you change all src for dst, just a variable name decision but a radical one... why was that (i honestly doesn't understand this patch very well ;)? That's because the first argument is not an input buffer, but an output buffer. MSDN also calls it 'strDest'. http://msdn.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx Linux manpage calls it 's', but I think it means String, not Src. http://man.cx/strftime If you can review the patch, please use the attached one instead. I modified it in response to the discussion of pg_do_encoding_conversion. BTW, I cannot understand the comment in the function head, + * result is obtained by locale setup of LC_TIME in the environment + * of windows at present CP_ACP. Therefore, conversion is needed + * for SERVER_ENCODING. SJIS which is not especially made to server + * encoding in Japan returns. but it probably says: strftime in Windows returns in CP_ACP encoding, but it could be different from SERVER_ENCODING. Especially, Windows Japanese edition requires conversions because it uses SJIS as CP_ACP, but we don't support SJIS as a server encoding. I hope you would review my English not only C ;-) Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Solve a problem of LC_TIME of windows.
Hi. I am sorry to be a very late reaction... Hiroshi Saito [EMAIL PROTECTED] writes: From: Magnus Hagander [EMAIL PROTECTED] Also, the patch needs error checking. strftime() can fail, and the multibyte conversion functions can certainly fail. That will need to be added. I will proposal the next patch.:-) next patch is this. Regards, Hiroshi Saito pg_locale_patch-v4 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] compilig libpq with borland 5.5
Hi. I made tests compiling both sources (from CVS repository and from HTTP), and i got the next results: 1-) MSVS 2005 *Source from CVS repository: *fatal error U1073: Don't know how to make 'libpq-dist.rc' *Source from http (ver. 8.3.3): **Successfully generated* It can be made from 'make distprep'. and def file is also made. However, I make it except windows environment. Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unable to build libpq on Win 2003 (32 bit)
Hi Nikolae-san. I tried by 8.3.0 which you use again. and VC++2005. Then, It does not reproduce a problem. http://winpg.jp/~saito/pg_work/pg8.3.0_nmake_VC++2005.txt I want to see your compile message. It is that one does not output an object as a very strange thing.?_? Regards, Hiroshi Saito - Original Message - From: Nikolae Shevchenco (md) [EMAIL PROTECTED] Hi Hiroshi, Thanks for your reply. Sorry I may have missed something but I'm using Visual Studio 2005. Anyway I'm sending you the dir Release output: C:\src\PostgreSQL\postgresql-8.3.0\src\interfaces\libpq\Releasedir Volume in drive C has no label. Volume Serial Number is 40C0-3D67 Directory of C:\src\PostgreSQL\postgresql-8.3.0\src\interfaces\libpq\Release 08/06/2008 01:47 PMDIR . 08/06/2008 01:47 PMDIR .. 08/05/2008 07:14 PM 776 libpq.res 1 File(s)776 bytes 2 Dir(s) 16,525,180,928 bytes free As you can see only one file is here - libpq.res. Any suggestions to get this fixed? I'm looking forward to your reply. Many thanks, Nikolay. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unable to build libpq on Win 2003 (32 bit)
Hi. Umm, It is very strange... I can't do a check in the reason for not having the environment of win2003 now. sorry... Can you the following try? nmake -f win32 /D CPU=i386 and, the output of the set command may be helpful. Regards, Hiroshi Saito - Original Message - From: Nikolae Shevchenco (md) [EMAIL PROTECTED] Hi Hiroshi, Thank you for your time. BTW I was trying to compile on different machine with Win XP and a build was successful. However I still have issues trying to compile on my machine with Win Server 2003 maybe the root cause is lying on that? I'm sending you output of the make command: C:\src\PostgreSQL\postgresql-8.3.0\src\interfaces\libpqnmake /f win32.mak 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 if not exist .\Release/ mkdir .\Release link.exe -lib @C:\DOCUME~1\MD_NSH~1\LOCALS~1\Temp\nm214.tmp LINK : fatal error LNK1181: cannot open input file 'LIB32_OBJS=' NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\link.exe' : return code '0x49d' Stop. C:\src\PostgreSQL\postgresql-8.3.0\src\interfaces\libpq I am looking forward to your reply. Many thanks, Nikolay. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unable to build libpq on Win 2003 (32 bit)
Hi. Sorry late reaction.. VC++2008 are official and are not supported. However, it has Build(ed). Then, I did not reproduce a problem. http://winpg.jp/~saito/pg_work/pg8.3.3_nmake_VC++2008.txt It seems that there is some version difference. Please show dir Release. Regards, Hiroshi Saito - Original Message - From: Nikolae Shevchenco (md) To: pgsql-hackers@postgresql.org Sent: Wednesday, August 06, 2008 2:33 AM Subject: [HACKERS] unable to build libpq on Win 2003 (32 bit) Hello everybody, I am trying to build libpq.dll from the source on a WIN 2003 system, the make file is attached. I am using Microsoft Visual Studio 8 and below is the command and outcome I'm trying to perform: C:\src\PostgreSQL\postgresql-8.3.0\src\interfaces\libpqnmake /f win32.mak /I 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 -lib @C:\DOCUME~1\MD_NSH~1\LOCALS~1\Temp\nm10D.tmp link.exe @C:\DOCUME~1\MD_NSH~1\LOCALS~1\Temp\nm10E.tmp mt -manifest .\Release\libpq.dll.manifest -outputresource:.\Release\libpq.dll;2 Microsoft (R) Manifest Tool version 5.2.3790.2014 Copyright (c) Microsoft Corporation 2005. All rights reserved. mt.exe : general error c10100b1: Failed to load file .\Release\libpq.dll. The system cannot find the file specified. What do you I need to change to make the build process successful? I'm looking forward to your reply. Thanks in advance. Nikolay Shevchenko. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext intoPG core distribution?
Hi Marko-san. Great thanks!! Please correct one mistake of mine...sorry. This patch solved problem of win32.:-) Regards, Hiroshi Saito - Original Message - From: Marko Kreen [EMAIL PROTECTED] On 7/28/08, Marko Kreen [EMAIL PROTECTED] wrote: On 7/25/08, Hiroshi Saito [EMAIL PROTECTED] wrote: I tackled with hope temporarily. It seems that some adjustment is still required. http://winpg.jp/~saito/pg_work/plproxy/ However, windows user desires to use. Of course, it is also me. Regards, Hiroshi Saito Thanks, I applied the patch to CVS, with minor changes: - Use HAVE_SYS_SELECT_H instead of WIN32 for sys/select.h - Do SHLIB_LINK += instead of separate var. Could you please test the attached patch or CVS HEAD, whether everything works fine now? One more change - I replaced __attribute__((dllimport)) with PGDLLIMPORT, which seems more standard. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers Makefile_patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext intoPG core distribution?
Hi Marko-san. Thanks! It is comfortable.:-) Regards, Hiroshi Saito - Original Message - From: Marko Kreen [EMAIL PROTECTED] On 7/28/08, Hiroshi Saito [EMAIL PROTECTED] wrote: Please correct one mistake of mine...sorry. This patch solved problem of win32.:-) You mean the += -lws2_32 must be after PGXS? Ok, but moving the PGXS line is not right as it should after all variables are set. I moved the SHLIB_LINK += line instead. Please test. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext intoPG core distribution?
Hi. I tackled with hope temporarily. It seems that some adjustment is still required. http://winpg.jp/~saito/pg_work/plproxy/ However, windows user desires to use. Of course, it is also me. Regards, Hiroshi Saito From: Joshua D. Drake [EMAIL PROTECTED] On Fri, 2008-07-25 at 09:37 +0300, Asko Oja wrote: Hi One of reasons to get PL/proxy into core is to make it available to Windows users also. The idea is to get to the situation createlang plproxy mydb If we can achieve this without putting plproxy into core then i would like to hear how. If the installer project wants to use it on Windows they can. Of course that assumes that it runs on windows (I have no idea if it does). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Do we really want to migrate plproxy and citext intoPG core distribution?
What is stopping you? Whether or not it works on Windows has (or should have) nothing to do with whether or not it is in core. I think that plproxy is great. However, the windows user did not complain. Because, build was not easy. Therefore, pginstaller has not chosen. Then, I thought that I wanted to solvebut, I do not have a spare time. Are they unrelated? I'm sorry if it is a noise Regarding your patch, the change w.r.t. the CONST token looks a bit odd - can you explain what you're doing and why? Ad hoc in order to clarify a problem. Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] issues/experience with building postgres on Windows
Hi.
Sorry, very late reaction
I'm based on the environment of VC++2005 and MinGW by the reason for requiring
official
support. and since it does not have many resources, the environment of VC++2008 is
restricted.
Therefore, many suggestion can't be performed now:-(
- Original Message -
From: Martin Zaun [EMAIL PROTECTED]
(snip)
- locating a OSSP-UUID binary package for Windows
(.dll but no uuid.h with Hiroshi Saito's binary package?)
Ahh, sorry, Although I adjusted with Ralf-san of the official central figure of
OSSP,
I did not synchronize with the release timing of PostgreSQLThen, It was
limited
to guidance of my web page.
(snip)
- ossp-uuid
Downloaded source from http://www.ossp.org/pkg/lib/uuid/.
Problem: from where to get a ossp-uuid Windows binary?
Yeah, I will propose to Ralf-san.
(snip)
8) Getting a Windows OSSP-UUID library
Google found me a postgres hackers email thread with this link
http://winpg.jp/~saito/pg_work/OSSP_win32/
to 1.6.2 uuid-ossp.dll mingw-compiled by Hiroshi Saito. Thanks!
Problem: from where to get the also needed uuid.h?
I've seen that Hiroshi Saito has worked on a patch for building the
uuid-ossp package on Windows. I didn't succeed in building
ossp-uuid using wingw on Windows and took the shortcut of using
cygwin to generate the uuid.h.
But that hack didn't work, I'm getting linkage errors:
uuid.lib(uuid_str.obj) : error LNK2019: unresolved external symbol _va_copy referenced in
function _uuid_str_vasprintf
.\Release\uuid-ossp\uuid-ossp.dll : fatal error LNK1120: 1 unresolved externals
== Where can I find a complete ossp-uuid package for Windows?
Um, I do not understand Cygwin
Please try define of config.h
---
/* Predefined possible va_copy() implementation (id: ASS) */
#define __VA_COPY_USE_ASS(d, s) do { (d) = (s); } while (0)
---
Regards,
Hiroshi Saito
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MSVC 2003 compile error with pg8.3.3
Hi Jeff-san. Uga,,, Ok. Please try this. Thanks your perseverance. !! Regards, Hiroshi Saito - Original Message - From: Jeff McKenna [EMAIL PROTECTED] Hello Hiroshi-san, Your new win32.mak causes the following error with MSVC 2003: Creating library .\Release\libpqdll.lib and object .\Release \libpqdll.exp mt -manifest .\Release\libpq.dll.manifest -outputresource:. \Release\libp q.dll;2 Microsoft (R) Manifest Tool version 6.0.4071.0 Copyright (c) Microsoft Corporation 2004. All rights reserved. .\Release\libpq.dll.manifest:general error c1010070:Failed to load and parse the manifest. The system cannot find the file specified. NMAKE : fatal error U1077: 'mt' : return code '0x1f' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio .NET 2003\ VC7\BIN\nmake.exe' : return code '0x2' Stop. --- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ On 26-Jun-08, at 11:28 PM, Hiroshi Saito wrote: Hi Jeff-san. Would you replace this with src/interfaces/libpq/win32.mak and try it? I checked that there was no problem in construction of VC2005 by this change. Then, I think if you solve a problem and it should apply. Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers # Makefile for Microsoft Visual C++ 7.1-8.0 # Will build a static library libpq(d).lib #and a dynamic library libpq(d).dll with import library libpq(d)dll.lib # USE_SSL=1 will compile with OpenSSL # USE_KFW=1 will compile with kfw(kerberos for Windows) # DEBUG=1 compiles with debugging symbols # ENABLE_THREAD_SAFETY=1 compiles with threading enabled ENABLE_THREAD_SAFETY=1 # CPU=i386 or CPU environment of nmake.exe (AMD64 or IA64) !IF ($(CPU) == )||($(CPU) == i386) CPU=i386 !MESSAGE Building the Win32 static library... !MESSAGE !ELSEIF ($(CPU) == IA64)||($(CPU) == AMD64) ADD_DEFINES=/D WIN64 /Wp64 /GS ADD_SECLIB=bufferoverflowU.lib !MESSAGE Building the Win64 static library... !MESSAGE !ELSE !MESSAGE Please check a CPU=$(CPU) ? !MESSAGE CPU=i386 or AMD64 or IA64 !ERROR Make aborted. !ENDIF !IFDEF DEBUG OPT=/Od /Zi /MDd LOPT=/DEBUG DEBUGDEF=/D _DEBUG OUTFILENAME=libpqd !ELSE OPT=/O2 /MD LOPT= DEBUGDEF=/D NDEBUG OUTFILENAME=libpq !ENDIF !IF $(SSL_INC) == SSL_INC=C:\OpenSSL\include !MESSAGE Using default OpenSSL Include directory: $(SSL_INC) !ENDIF !IF $(SSL_LIB_PATH) == SSL_LIB_PATH=C:\OpenSSL\lib\VC !MESSAGE Using default OpenSSL Library directory: $(SSL_LIB_PATH) !ENDIF !IF $(KFW_INC) == KFW_INC=C:\kfw-2.6.5\inc !MESSAGE Using default Kerberos Include directory: $(KFW_INC) !ENDIF !IF $(KFW_LIB_PATH) == KFW_LIB_PATH=C:\kfw-2.6.5\lib\$(CPU) !MESSAGE Using default Kerberos Library directory: $(KFW_LIB_PATH) !ENDIF !IF $(OS) == Windows_NT NULL= !ELSE NULL=nul !ENDIF CPP=cl.exe RSC=rc.exe !IFDEF DEBUG OUTDIR=.\Debug INTDIR=.\Debug CPP_OBJS=.\Debug/ !ELSE OUTDIR=.\Release INTDIR=.\Release CPP_OBJS=.\Release/ !ENDIF ALL : config $(OUTDIR)\$(OUTFILENAME).lib $(OUTDIR)\$(OUTFILENAME).dll CLEAN : [EMAIL PROTECTED] $(INTDIR)\getaddrinfo.obj [EMAIL PROTECTED] $(INTDIR)\pgstrcasecmp.obj [EMAIL PROTECTED] $(INTDIR)\thread.obj [EMAIL PROTECTED] $(INTDIR)\inet_aton.obj [EMAIL PROTECTED] $(INTDIR)\crypt.obj [EMAIL PROTECTED] $(INTDIR)\noblock.obj [EMAIL PROTECTED] $(INTDIR)\md5.obj [EMAIL PROTECTED] $(INTDIR)\ip.obj [EMAIL PROTECTED] $(INTDIR)\fe-auth.obj [EMAIL PROTECTED] $(INTDIR)\fe-protocol2.obj [EMAIL PROTECTED] $(INTDIR)\fe-protocol3.obj [EMAIL PROTECTED] $(INTDIR)\fe-connect.obj [EMAIL PROTECTED] $(INTDIR)\fe-exec.obj [EMAIL PROTECTED] $(INTDIR)\fe-lobj.obj [EMAIL PROTECTED] $(INTDIR)\fe-misc.obj [EMAIL PROTECTED] $(INTDIR)\fe-print.obj [EMAIL PROTECTED] $(INTDIR)\fe-secure.obj [EMAIL PROTECTED] $(INTDIR)\pqexpbuffer.obj [EMAIL PROTECTED] $(INTDIR)\pqsignal.obj [EMAIL PROTECTED] $(INTDIR)\win32.obj [EMAIL PROTECTED] $(INTDIR)\wchar.obj [EMAIL PROTECTED] $(INTDIR)\encnames.obj [EMAIL PROTECTED] $(INTDIR)\pthread-win32.obj [EMAIL PROTECTED] $(INTDIR)\snprintf.obj [EMAIL PROTECTED] $(INTDIR)\strlcpy.obj [EMAIL PROTECTED] $(INTDIR)\dirent.obj [EMAIL PROTECTED] $(INTDIR)\dirmod.obj [EMAIL PROTECTED] $(INTDIR)\pgsleep.obj [EMAIL PROTECTED] $(INTDIR)\open.obj [EMAIL PROTECTED] $(INTDIR)\win32error.obj [EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME).lib [EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME)dll.lib [EMAIL PROTECTED] $(OUTDIR)\libpq.res [EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME).dll [EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME)dll.exp [EMAIL PROTECTED] $(OUTDIR)\$(OUTFILENAME).dll.manifest [EMAIL PROTECTED] $(OUTDIR
Re: [HACKERS] MSVC 2003 compile error with pg8.3.3
Ooops, I am sorry so that it may be spam. ... I have noticed, although there were few conditions. pass the VC6,VC7,VC71 Regards, Hiroshi Saito - Original Message - From: Hiroshi Saito [EMAIL PROTECTED] Hi Jeff-san. Uga,,, Ok. Please try this. Thanks your perseverance. !! Regards, Hiroshi Saito - Original Message - From: Jeff McKenna [EMAIL PROTECTED] Hello Hiroshi-san, Your new win32.mak causes the following error with MSVC 2003: Creating library .\Release\libpqdll.lib and object .\Release \libpqdll.exp mt -manifest .\Release\libpq.dll.manifest -outputresource:. \Release\libp q.dll;2 Microsoft (R) Manifest Tool version 6.0.4071.0 Copyright (c) Microsoft Corporation 2004. All rights reserved. .\Release\libpq.dll.manifest:general error c1010070:Failed to load and parse the manifest. The system cannot find the file specified. NMAKE : fatal error U1077: 'mt' : return code '0x1f' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio .NET 2003\ VC7\BIN\nmake.exe' : return code '0x2' Stop. --- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ On 26-Jun-08, at 11:28 PM, Hiroshi Saito wrote: Hi Jeff-san. Would you replace this with src/interfaces/libpq/win32.mak and try it? I checked that there was no problem in construction of VC2005 by this change. Then, I think if you solve a problem and it should apply. Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers # Makefile for Microsoft Visual C++ 7.1-8.0 # Will build a static library libpq(d).lib #and a dynamic library libpq(d).dll with import library libpq(d)dll.lib # USE_SSL=1 will compile with OpenSSL # USE_KFW=1 will compile with kfw(kerberos for Windows) # DEBUG=1 compiles with debugging symbols # ENABLE_THREAD_SAFETY=1 compiles with threading enabled ENABLE_THREAD_SAFETY=1 # CPU=i386 or CPU environment of nmake.exe (AMD64 or IA64) !IF ($(CPU) == )||($(CPU) == i386) CPU=i386 !MESSAGE Building the Win32 static library... !MESSAGE !ELSEIF ($(CPU) == IA64)||($(CPU) == AMD64) ADD_DEFINES=/D WIN64 /Wp64 /GS ADD_SECLIB=bufferoverflowU.lib !MESSAGE Building the Win64 static library... !MESSAGE !ELSE !MESSAGE Please check a CPU=$(CPU) ? !MESSAGE CPU=i386 or AMD64 or IA64 !ERROR Make aborted. !ENDIF !IFDEF DEBUG OPT=/Od /Zi /MDd LOPT=/DEBUG DEBUGDEF=/D _DEBUG OUTFILENAME=libpqd !ELSE OPT=/O2 /MD LOPT= DEBUGDEF=/D NDEBUG OUTFILENAME=libpq !ENDIF !IF $(SSL_INC) == SSL_INC=C:\OpenSSL\include !MESSAGE Using default OpenSSL Include directory: $(SSL_INC) !ENDIF !IF $(SSL_LIB_PATH) == SSL_LIB_PATH=C:\OpenSSL\lib\VC !MESSAGE Using default OpenSSL Library directory: $(SSL_LIB_PATH) !ENDIF !IF $(KFW_INC) == KFW_INC=C:\kfw-2.6.5\inc !MESSAGE Using default Kerberos Include directory: $(KFW_INC) !ENDIF !IF $(KFW_LIB_PATH) == KFW_LIB_PATH=C:\kfw-2.6.5\lib\$(CPU) !MESSAGE Using default Kerberos Library directory: $(KFW_LIB_PATH) !ENDIF !IF $(OS) == Windows_NT NULL= !ELSE NULL=nul !ENDIF CPP=cl.exe RSC=rc.exe !IFDEF DEBUG OUTDIR=.\Debug INTDIR=.\Debug CPP_OBJS=.\Debug/ !ELSE OUTDIR=.\Release INTDIR=.\Release CPP_OBJS=.\Release/ !ENDIF ALL : config $(OUTDIR)\$(OUTFILENAME).lib $(OUTDIR)\$(OUTFILENAME).dll CLEAN : [EMAIL PROTECTED] $(INTDIR)\getaddrinfo.obj [EMAIL PROTECTED] $(INTDIR)\pgstrcasecmp.obj [EMAIL PROTECTED] $(INTDIR)\thread.obj [EMAIL PROTECTED] $(INTDIR)\inet_aton.obj [EMAIL PROTECTED] $(INTDIR)\crypt.obj [EMAIL PROTECTED] $(INTDIR)\noblock.obj [EMAIL PROTECTED] $(INTDIR)\md5.obj [EMAIL PROTECTED] $(INTDIR)\ip.obj [EMAIL PROTECTED] $(INTDIR)\fe-auth.obj [EMAIL PROTECTED] $(INTDIR)\fe-protocol2.obj [EMAIL PROTECTED] $(INTDIR)\fe-protocol3.obj [EMAIL PROTECTED] $(INTDIR)\fe-connect.obj [EMAIL PROTECTED] $(INTDIR)\fe-exec.obj [EMAIL PROTECTED] $(INTDIR)\fe-lobj.obj [EMAIL PROTECTED] $(INTDIR)\fe-misc.obj [EMAIL PROTECTED] $(INTDIR)\fe-print.obj [EMAIL PROTECTED] $(INTDIR)\fe-secure.obj [EMAIL PROTECTED] $(INTDIR)\pqexpbuffer.obj [EMAIL PROTECTED] $(INTDIR)\pqsignal.obj [EMAIL PROTECTED] $(INTDIR)\win32.obj [EMAIL PROTECTED] $(INTDIR)\wchar.obj [EMAIL PROTECTED] $(INTDIR)\encnames.obj [EMAIL PROTECTED] $(INTDIR)\pthread-win32.obj [EMAIL PROTECTED] $(INTDIR)\snprintf.obj [EMAIL PROTECTED] $(INTDIR)\strlcpy.obj [EMAIL PROTECTED] $(INTDIR)\dirent.obj [EMAIL PROTECTED] $(INTDIR)\dirmod.obj [EMAIL PROTECTED] $(INTDIR)\pgsleep.obj
Re: [HACKERS] MSVC 2003 compile error with pg8.3.3
Hi Jeff-san. Thanks!! The version which you use is supported officially. http://www.postgresql.org/docs/8.3/static/install-win32-libpq.html To build the libpq client library using Visual Studio 7.1 or later. However, adjustment may be necessity. I will propose patch.! Regards, Hiroshi Saito - Original Message - From: Jeff McKenna [EMAIL PROTECTED] Hiroshi-san, All win32 parts have been built! That last file that you sent worked with MSVC 2003, and libpq.dll was successfully built. Thank you very much for fixing this for me. Will this be committed to CVS head for others? --- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ On 27-Jun-08, at 11:55 AM, Hiroshi Saito wrote: Ooops, I am sorry so that it may be spam. ... I have noticed, although there were few conditions. pass the VC6,VC7,VC71 Regards, Hiroshi Saito - Original Message - From: Hiroshi Saito [EMAIL PROTECTED] Hi Jeff-san. Uga,,, Ok. Please try this. Thanks your perseverance. !! Regards, Hiroshi Saito - Original Message - From: Jeff McKenna [EMAIL PROTECTED] Hello Hiroshi-san, Your new win32.mak causes the following error with MSVC 2003: Creating library .\Release\libpqdll.lib and object .\Release \libpqdll.exp mt -manifest .\Release\libpq.dll.manifest -outputresource:. \Release\libp q.dll;2 Microsoft (R) Manifest Tool version 6.0.4071.0 Copyright (c) Microsoft Corporation 2004. All rights reserved. .\Release\libpq.dll.manifest:general error c1010070:Failed to load and parse the manifest. The system cannot find the file specified. NMAKE : fatal error U1077: 'mt' : return code '0x1f' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio .NET 2003\ VC7\BIN\nmake.exe' : return code '0x2' Stop. --- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ On 26-Jun-08, at 11:28 PM, Hiroshi Saito wrote: Hi Jeff-san. Would you replace this with src/interfaces/libpq/win32.mak and try it? I checked that there was no problem in construction of VC2005 by this change. Then, I think if you solve a problem and it should apply. Regards, Hiroshi Saito -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers win32.mak -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MSVC 2003 compile error with pg8.3.3
Hi.
Um, Please try this.
#includewindows.h
extern void __cdecl _dosmaperr( unsigned long oserrno );
int main(int argc, char *argv[])
{
_dosmaperr(GetLastError());
return(0);
}
Can errorless compile be performed?
Regards,
Hiroshi Saito
- Original Message -
From: Jeff McKenna [EMAIL PROTECTED]
To: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Thursday, June 26, 2008 10:04 PM
Subject: Re: [HACKERS] MSVC 2003 compile error with pg8.3.3
Thanks Hiroshi. Unfortunately libpq.dll does not compile with MSVC
2003. Has anyone successfully compiled libpq for 8.3.3 (or CVS head)
with MSVC 2003??
---
Jeff McKenna
FOSS4G Consulting and Training Services
http://www.gatewaygeomatics.com/
On 24-Jun-08, at 8:31 PM, Hiroshi Saito wrote:
Hi.
It is strange...
Problem is not reproduced although I use VC2005.
The result of my nmake -f win32.mak is this. ...
Microsoft (R) Manifest Tool version 5.2.3790.2014
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
cd ..\..
echo All Win32 parts have been built!
All Win32 parts have been built!
C:\MinGW\home\HIROSHI\postgresql-8.3.3\src
It may be necessary to investigate the reference relation of VC2003.
Does someone notice some?
Regards,
Hiroshi Saito
- Original Message - From: Jeff McKenna [EMAIL PROTECTED]
Hello,
I am trying to compile libpq.dll with MSVC 2003 on windows, using
postgresql-8.3.3, but I get the following compile error:
Creating library .\Release\libpqdll.lib and object .\Release
\libpqdll.exp
libpq.lib(dirmod.obj) : error LNK2019: unresolved external symbol
__dosmaperr r
ferenced in function _pgwin32_safestat
libpq.lib(dirent.obj) : error LNK2001: unresolved external symbol
__dosmaperr
.\Release\libpq.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'link.exe' : return code '0x460'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual
Studio .NET 2003
VC7\BIN\nmake.exe' : return code '0x2'
Stop.
Does anyone have any ideas how to solve this??
thanks.
-jeff
---
Jeff McKenna
FOSS4G Consulting and Training Services
http://www.gatewaygeomatics.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] MSVC 2003 compile error with pg8.3.3
Hi Jeff-san.
Would you replace this with src/interfaces/libpq/win32.mak and try it?
I checked that there was no problem in construction of VC2005 by this
change. Then, I think if you solve a problem and it should apply.
Regards,
Hiroshi Saito
- Original Message -
From: Jeff McKenna [EMAIL PROTECTED]
For the record, I just compiled libpq.dll successfully with pg8.2.3
and MSVC 2003...so something is causing troubles in pg8.3.3 with this
compiler version. Hiroshi let me know where to place that test code,
thanks.
---
Jeff McKenna
FOSS4G Consulting and Training Services
http://www.gatewaygeomatics.com/
On 26-Jun-08, at 3:12 PM, Jeff McKenna wrote:
Hi Hiroshi. What exact file am I to place your test in? win32.h on
line#290 ?
---
Jeff McKenna
FOSS4G Consulting and Training Services
http://www.gatewaygeomatics.com/
On 26-Jun-08, at 12:42 PM, Hiroshi Saito wrote:
Hi.
Um, Please try this.
#includewindows.h
extern void __cdecl _dosmaperr( unsigned long oserrno );
int main(int argc, char *argv[])
{
_dosmaperr(GetLastError());
return(0);
}
Can errorless compile be performed?
Regards,
Hiroshi Saito
- Original Message - From: Jeff McKenna [EMAIL PROTECTED]
To: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Thursday, June 26, 2008 10:04 PM
Subject: Re: [HACKERS] MSVC 2003 compile error with pg8.3.3
Thanks Hiroshi. Unfortunately libpq.dll does not compile with
MSVC 2003. Has anyone successfully compiled libpq for 8.3.3 (or
CVS head) with MSVC 2003??
---
Jeff McKenna
FOSS4G Consulting and Training Services
http://www.gatewaygeomatics.com/
On 24-Jun-08, at 8:31 PM, Hiroshi Saito wrote:
Hi.
It is strange...
Problem is not reproduced although I use VC2005.
The result of my nmake -f win32.mak is this. ...
Microsoft (R) Manifest Tool version 5.2.3790.2014
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
cd ..\..
echo All Win32 parts have been built!
All Win32 parts have been built!
C:\MinGW\home\HIROSHI\postgresql-8.3.3\src
It may be necessary to investigate the reference relation of
VC2003.
Does someone notice some?
Regards,
Hiroshi Saito
- Original Message - From: Jeff McKenna [EMAIL PROTECTED]
Hello,
I am trying to compile libpq.dll with MSVC 2003 on windows,
using postgresql-8.3.3, but I get the following compile error:
Creating library .\Release\libpqdll.lib and object .\Release
\libpqdll.exp
libpq.lib(dirmod.obj) : error LNK2019: unresolved external
symbol __dosmaperr r
ferenced in function _pgwin32_safestat
libpq.lib(dirent.obj) : error LNK2001: unresolved external
symbol __dosmaperr
.\Release\libpq.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'link.exe' : return code '0x460'
Stop.
NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual
Studio .NET 2003
VC7\BIN\nmake.exe' : return code '0x2'
Stop.
Does anyone have any ideas how to solve this??
thanks.
-jeff
---
Jeff McKenna
FOSS4G Consulting and Training Services
http://www.gatewaygeomatics.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
# Makefile for Microsoft Visual C++ 7.1-8.0
# Will build a static library libpq(d).lib
#and a dynamic library libpq(d).dll with import library libpq(d)dll.lib
# USE_SSL=1 will compile with OpenSSL
# USE_KFW=1 will compile with kfw(kerberos for Windows)
# DEBUG=1 compiles with debugging symbols
# ENABLE_THREAD_SAFETY=1 compiles with threading enabled
ENABLE_THREAD_SAFETY=1
# CPU=i386 or CPU environment of nmake.exe (AMD64 or IA64)
!IF ($(CPU) == )||($(CPU) == i386)
CPU=i386
!MESSAGE Building the Win32 static library...
!MESSAGE
!ELSEIF ($(CPU) == IA64)||($(CPU) == AMD64)
ADD_DEFINES=/D WIN64 /Wp64 /GS
ADD_SECLIB=bufferoverflowU.lib
!MESSAGE Building the Win64 static library...
!MESSAGE
!ELSE
!MESSAGE Please check a CPU=$(CPU) ?
!MESSAGE CPU=i386 or AMD64 or IA64
!ERROR Make aborted.
!ENDIF
!IFDEF DEBUG
OPT=/Od /Zi /MDd
LOPT=/DEBUG
DEBUGDEF=/D _DEBUG
OUTFILENAME=libpqd
!ELSE
OPT=/O2 /MD
LOPT=
DEBUGDEF=/D NDEBUG
OUTFILENAME=libpq
!ENDIF
Re: [HACKERS] MSVC 2003 compile error with pg8.3.3
Hi. It is strange... Problem is not reproduced although I use VC2005. The result of my nmake -f win32.mak is this. ... Microsoft (R) Manifest Tool version 5.2.3790.2014 Copyright (c) Microsoft Corporation 2005. All rights reserved. cd ..\.. echo All Win32 parts have been built! All Win32 parts have been built! C:\MinGW\home\HIROSHI\postgresql-8.3.3\src It may be necessary to investigate the reference relation of VC2003. Does someone notice some? Regards, Hiroshi Saito - Original Message - From: Jeff McKenna [EMAIL PROTECTED] Hello, I am trying to compile libpq.dll with MSVC 2003 on windows, using postgresql-8.3.3, but I get the following compile error: Creating library .\Release\libpqdll.lib and object .\Release \libpqdll.exp libpq.lib(dirmod.obj) : error LNK2019: unresolved external symbol __dosmaperr r ferenced in function _pgwin32_safestat libpq.lib(dirent.obj) : error LNK2001: unresolved external symbol __dosmaperr .\Release\libpq.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Stop. NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio .NET 2003 VC7\BIN\nmake.exe' : return code '0x2' Stop. Does anyone have any ideas how to solve this?? thanks. -jeff --- Jeff McKenna FOSS4G Consulting and Training Services http://www.gatewaygeomatics.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] OSSP can be used in the windows environment now!
Hi. - Original Message - From: Tom Lane [EMAIL PROTECTED] I'd like somebody to close the loop with upstream OSSP authors first. If they don't see anything broken about the makefile, and indicate intention to incorporate it in some future release, then it's okay to put it in our CVS temporarily. If they don't like it then we'd better understand why. There's also the possibility that they put out a release including it next week, in which case we hardly need it in our CVS. Um, I was hesitating the proposal by the reason which is not beautiful. However, it turns out that it is solvable by a little working hours. Therefore, It is due for me to do the work.I think, It is because of the wonderfulness of PostgreSQL. But, since MinGW+GCC can already be used, the problem is whether to provide by pginstaller. then, we have intension necessity in it. Then, An objection will not realize it. 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: [HACKERS] OSSP can be used in the windows environment now!
Hi. - Original Message - From: Dave Page [EMAIL PROTECTED] On Thu, Feb 28, 2008 at 12:22 PM, Magnus Hagander [EMAIL PROTECTED] wrote: If not, what do other people think about adding this Makefile and a README file to our contrib directory? If there is no contrary opinion, I believe that it is help to many people's Comments from others? Objections? If it's well documented which versions of MSVC++ work with it, and which versions of ossp-uuid, I don't see it as a major problem to include it. It's annoying for sure, but it's not the end of the world. Yeah:-) Ok, I will write README and desire to be applied by your refereeing and an arrangement.! Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] OSSP can be used in the windows environment now!
Hi. - Original Message - From: Magnus Hagander [EMAIL PROTECTED] What exactly is needed for building the required libuuid files? rom what I can tell, the authorh as no binaries available, correct? Yes, both can be built. however, msvc-build is not official though regrettable. but, It can be built without source-code changing. It is created as our module. http://winpg.jp/~saito/pg_work/OSSP_win32/msvc/ I have checked by examination. It builds with mingw only? Or with msvc? does the mingw build generate all the required libraries for the msvc build as well? (sorry, I'm on a win64 box right now, so mingw doesn't work at all, so I can't test that right now) Therefore, It has built in the environment of both now. Also, documentation updates will be needed, but I can handle those. Yeah:-) 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
Re: [HACKERS] OSSP can be used in the windows environment now!
Hi. - Original Message - From: Magnus Hagander [EMAIL PROTECTED] Ok. Do you know if there are any plans to include this in the distribution? I would make life a whole lot easier. If not, perhaps we should include the win32.mak file in a subdir to our uuid module? Ahh, I don't have a good idea... build of MinGW is required before win32.mak. Probably, it needs to be written to a document. I found a couple of other problems with your patch, but i'ev been able to fix those. Building a test with msvc now, and will write documentation. Thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] OSSP can be used in the windows environment now!
Hi. - Original Message - From: Magnus Hagander [EMAIL PROTECTED] I take it you are in contact with them, since you helped them with the port? Can you ask them if they are interested in distributing that file? Yes, However, It is not discussing about MSVC. It is because it needed to think with correspondence of the generation process (xx.in) of the source code. Furthermore, uuid_cli had a problem more... Although I don't have the margin time now, it is taken as my TODO. If not, what do other people think about adding this Makefile and a README file to our contrib directory? If there is no contrary opinion, I believe that it is help to many people's Regards, Hiroshi Saito ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] OSSP can be used in the windows environment now!
Hi. Please check it. build is successful for it in my environment. Thanks! Regards, Hiroshi Saito - Original Message - From: Hiroshi Saito [EMAIL PROTECTED] Hi. From: Magnus Hagander [EMAIL PROTECTED] we can include in the next release.:-) Thanks! Good news. Can you provide a patch for the msvc build system to build with it? We can't really ship it in the next release if we can't build with it ;-) Ahh Ok, I try it first and need to check clear environment. Probably, Monday will come by the reason I'm very busy. Thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq msvc_uuid_patch Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] OSSP can be used in the windows environment now!
Hi. From: Magnus Hagander [EMAIL PROTECTED] we can include in the next release.:-) Thanks! Good news. Can you provide a patch for the msvc build system to build with it? We can't really ship it in the next release if we can't build with it ;-) Ahh Ok, I try it first and need to check clear environment. Probably, Monday will come by the reason I'm very busy. Thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] OSSP can be used in the windows environment now!
Hi all. The door was opened by Mr. Ralf S. Engelschall of a great developer. http://www.ossp.org/pkg/lib/uuid/ It can be used from Version 1.6.1. Please see, http://winpg.jp/~saito/pg_work/OSSP_win32/ we can include in the next release.:-) Thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] NLS on MSVC strikes back!
Hi. Still, my health is not good... First, Probably, as for the 8.3 release binary, NLS is offed. Even if it arranges shar/locale, it is not used. Next, NLS was confirmed by VCBUILD of CVS-HEAD. A very interesting result can be seen here. http://inet.winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/ It was expressed by LC_MESSAGE=C. Anyway, in Japan, it is hard to use.. 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: [HACKERS] NLS on MSVC strikes back!
Hi Alvaro-san. Yes, However, It is not in good condition at the reason a message catalog still is not enough. Then, I have tried these adjustments with the problem of a locale. Still, it is not much time. But, My condition is not good so that I'm may be influenza. :-( Regards, Hiroshi Saito - Original Message - From: Alvaro Herrera [EMAIL PROTECTED] Hiroshi Saito wrote: Hi --Document.-- Table 9-22. TM prefix translation mode (print localized day and month names based on lc_messages) -- http://winpg.jp/~saito/pg_work/NLS_TO_CHAR_JP.png But, Although Japanese is out of condition Does the fundamental specification change? Humm, I cannot read Japanese so as far as I can make, this is working fine? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] NLS on MSVC strikes back!
From: Alvaro Herrera [EMAIL PROTECTED] Dave Page wrote: On Feb 12, 2008 4:44 PM, Alvaro Herrera [EMAIL PROTECTED] wrote: What this really means is that locale support is completely broken in the MSVC build, i.e. you cannot get localized strings at all (not just to_char()). Is this correct? If so, this is a serious problem. Not judging by Hiroshi's screenshot. I don't speak Japanese either, but it certainly didn't say 'tuesday' after he adjusted LC_MESSAGES. But it has the string mingw in the path, so I suspect it's not MSVC ... Hiroshi-san, can you confirm? Yeah, However, I go to a hospital from now sorry. I will check it, after returning. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] NLS on MSVC strikes back!
Hi --Document.-- Table 9-22. TM prefix translation mode (print localized day and month names based on lc_messages) -- http://winpg.jp/~saito/pg_work/NLS_TO_CHAR_JP.png But, Although Japanese is out of condition Does the fundamental specification change? Regards, Hiroshi Saito - Original Message - From: Alvaro Herrera [EMAIL PROTECTED] Gevik Babakhani wrote: I have compiled 8.3 (CVS HEAD) with NLS on a XP box. But it seems that NLS support is broke. Could someone please confirm this. What I can confirm is that lc_messages is supposed to work for to_char, because it shows the localized output for me as I change lc_messages; and it doesn't if I change lc_time. In any case, Gevik=# show lc_messages ; lc_messages English_United States.1252 (1 row) Gevik=# Gevik=# set lc_messages TO 'de_DE.utf8'; SET I wonder if this is really valid. Shouldn't you be using a locale name like 'German_Germany.65001' or some such? I thought Windows did not recognize the de_DE.utf8 form of names. Perhaps it failed to raise an error here? It does for me: alvherre=# set lc_time to 'fr_CA.utf8'; SET alvherre=# set lc_time to 'de_DE.utf8'; ERROR: valor no válido para el parámetro «lc_time»: «de_DE.utf8» Suffice to say I don't have the de_DE locale installed. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] AS by the syntax of table reference.(8.4 proposal)
Hi. From: Tom Lane [EMAIL PROTECTED] A possibly bigger problem is that the solution for postfix ops doesn't scale nicely: we'd have to list not only IDENT, but *every* can-be-ColId keyword, in the %precedence list, which (a) is a maintenance headache, (b) causes a conflict because some are already listed there with the wrong precedence for this purpose, and (c) is very scary from the viewpoint of possibly silently suppressing warnings of future grammar ambiguities. I'm not even that happy with giving IDENT a precedence; giving precedences to 270 or so currently precedence-less tokens just doesn't sound safe. Yeah, when I began, I tried the method same as a_expr IDENT as you. That is because I thought that it was effective in order to avoid a conflict simply. It is worried that it may cause the problem of next operation by the reason IDENT is not the simple token. Therefore, c_expr IDENT of the method of doing with a basic rule was proposed. However, If it is allowed in the place which you consider, I don't have an objection. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] The question of LOCALE at the time of a regression test.
Hi Tom-san.
I look at that all regression tests pass by tools/msvc. It is very comfortable.!
Then, the reason, it is because no-locale is an default value.
--
my @args = (
../../../$Config/pg_regress/pg_regress,
--psqldir=../../../$Config/psql,
--schedule=${schedule}_schedule,
--multibyte=SQL_ASCII,
--load-language=plpgsql,
--no-locale
--
It is why here. -- Is it no-locale?
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
[HACKERS] AS by the syntax of table reference.(8.4 proposal)
Hi all. I thinks to the option of AS by the syntax of table reference. The problem on structure had restricted it until now. Then, conversion was required of this by the degree of migration from other DBMS's. It was irritated a little. I understood that it was an option in SQL2003 and SQL99. -- SQL2003 7.6 table reference (p303) table or query name [ [ AS ] correlation name -- I propose this. However, postfix operators is troublesome. Therefore, This is the inclusion with restriction. I think that it is a trifling problem. But, The past compatibility is worried very much. Then, many developers' clear eye is required for it. However, I need this patch very much. about regression error of the after patch This is as a result of after patch apply of CVS-HEAD regression. The cause changed the error position of a grammar interpretation. -- plpgsql ... FAILED 1 of 114 tests failed. *** ./expected/plpgsql.out Wed Jul 25 13:19:09 2007 --- ./results/plpgsql.out Fri Jan 25 14:29:34 2008 *** *** 2337,2343 end loop; return 5; end;$$ language plpgsql; ! ERROR: syntax error at or near fought LINE 1: select I fought the law, the law won ^ QUERY: select I fought the law, the law won --- 2337,2343 end loop; return 5; end;$$ language plpgsql; ! ERROR: syntax error at or near the LINE 1: select I fought the law, the law won ^ QUERY: select I fought the law, the law won == about postfix operator problem There is syntax which is not passed. However, It is necessary to make it c_expr expression. Probably, it is avoided by cautions of a document. -- regression=# SELECT aa AS X FROM a_star LIMIT 1; X --- 1 (1 row) regression=# SELECT aa ! AS X FROM a_star LIMIT 1; X --- 1 (1 row) regression=# SELECT aa ! X FROM a_star LIMIT 1; ERROR: column X does not exist LINE 1: SELECT aa ! X FROM a_star LIMIT 1; ^ regression=# SELECT (aa !) X FROM a_star LIMIT 1; X --- 1 (1 row) -- BTW, this is the syntax which ORACLE and SQLServer don't accept. It may be the wonderfulness of PostgreSQL. However, Is there any situation using the function? But, I can't do assertion. In conclusion, Therefore, this will be left to vote. Regards, Hiroshi Saito as_less_patch Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] The question of LOCALE at the time of a regression test.
Hi. From: Andrew Dunstan [EMAIL PROTECTED] I stand corrected. I know I had enough trouble even before we started doing Windows builds that we had to use --no-locale in the buildfarm (or at least that was the solution I adopted). For example, I know of cases where FBSD and Linux don't agree even on collation order for quite common locales. But by all means let's see what happens on Windows when we take the flag out. Hiroshi-san, perhaps you would like to test it and see? At least, it wishes as a thing of the user of not only me but many. Thanks! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] The question of LOCALE at the time of a regression test.
Hi Tom-san. From: Tom Lane [EMAIL PROTECTED] Andrew Dunstan [EMAIL PROTECTED] writes: Since we rely on the OS to supply locale settings, getting a reliable set of regression tests that depended on the locale would be close to impossible. We really have to run the regression tests under --no-locale. This is quite untrue; we have variant regression files that exist specifically to support running the tests under various popular locales. As Hiroshi-san points out, --no-locale isn't even the default in the Unix makefile. Perhaps the Windows locales are different enough that what we have doesn't cover them? Um, I was flipped off by you http://archives.postgresql.org/pgsql-patches/2007-10/msg00070.php ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] The question of LOCALE at the time of a regression test.
Um, I was flipped off by you You shouldn't go around flipping people off: it's rude :) http://www.merriam-webster.com/dictionary/flip%20off Ah sorry, I was the reason referred to as being an aphasic. It was not meant expression. :-( However, I think then that I was not fair. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] AS by the syntax of table reference.(8.4 proposal)
Oops, and, so we really need to support at least ColId as the allowed set of column alias names. (I tried changing the patch to do that, but got a lot of shift/reduce conflicts, some of which are maybe fixable but some seem hard to fix.) Since capability was insufficient, I spent several times as many time as this. It understands the very hard thing. Hardship had left traces upon this features. I want me to still inquire. 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: [HACKERS] AS by the syntax of table reference.(8.4 proposal)
Hi. - Original Message - From: Tom Lane [EMAIL PROTECTED] Hmm, since c_expr is so restrictive, is that really going to satisfy anybody who expects to be able to omit AS? With the number of unreserved keywords we have, the restriction to IDENT for the label seems like it's going to be a constant source of gotchas as well. Both of these limitations are contrary to the SQL spec, too --- SQL99 says that a SELECT-list element is derived column ::= value expression [ as clause ] as clause ::= [ AS ] column name Ahhh yes so we really need to support at least ColId as the allowed set of column alias names. (I tried changing the patch to do that, but got a lot of shift/reduce conflicts, some of which are maybe fixable but some seem hard to fix.) I think that simply saying it's not supported is going to be easier to deal with than people trying to use it and complaining that this or that case doesn't work. Um, I think that it is supported by AS. Then, How to use as before is allowed. I think that I do not see a complaint to it. Although what is told clearly is desired, I think that there are many people needed. Therefore, it is believed that this needs to hear many opinions. I'm violently required. I'm looking at such realization. http://winpg.jp/~saito/psqlODBC/SQLServer_linkserver_PostgreSQL2.png PostgreSQL works hard in a fit place. !! And a system will be operated in cooperation. :-) Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] The question of LOCALE at the time of a regression test.
Hi. I apologizes for impoliteness. sorry. I cause misapprehension since telling well is difficult for me. From: Tom Lane [EMAIL PROTECTED] It's certainly possible that some of the buildfarm machines use locales that haven't been covered --- or at least weren't covered when you started that project; we fixed things for sv_SE just a couple months ago, for instance. I'm not sure whether it'd be sane to promise that we'd make the regression tests work on any locale at all. But I agree that it's worth experimenting to see where they do or don't work now. I think that clear information is required for the solution in problem. anyway, 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
Re: [HACKERS] The question of LOCALE at the time of a regression test.
Hi Andrew-san. Thanks! - Original Message - From: Andrew Dunstan [EMAIL PROTECTED] Hiroshi Saito wrote: Hi Tom-san. I look at that all regression tests pass by tools/msvc. It is very comfortable.! Then, the reason, it is because no-locale is an default value. Since we rely on the OS to supply locale settings, getting a reliable set of regression tests that depended on the locale would be close to impossible. We really have to run the regression tests under --no-locale. It is very strange... GNUmakefile is this -- # locale NOLOCALE = ifdef NO_LOCALE NOLOCALE += --no-locale endif -- It is inconsistent. although I was a problem of Japan, I proposed it. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] AS by the syntax of table reference.(8.4 proposal)
Sorry, I'm sleeping.
Thanks Gregory-san. and, Tom-san.
Gregory Stark [EMAIL PROTECTED] writes:
But yeah, c_expr isn't enough. We really need {a,b}_expr sans postfix
expressions.
How's that going to help? As long as postfix operators exist at all,
SELECT a + b, ...
is going to be ambiguous, and no amount of grammar magic changes that.
We could force the parser into using one interpretation or the other,
but it would still be wrong for some folks.
Ah yes, {a,b}_expr is very difficult.Then, I am asking for compromise.
at the c_expr, case after the patch..
postgres=# select a+b from n;
?column?
--
5
(1 row)
postgres=# select a+b AS FIELD from n;
FIELD
---
5
(1 row)
postgres=# select a+b FIELD from n;
ERROR: syntax error at or near FIELD
LINE 1: select a+b FIELD from n;
^
postgres=# select (a+b) FIELD from n;
FIELD
---
5
(1 row)
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] AS by the syntax of table reference.(8.4 proposal)
Hi Andrew-san. - Original Message - From: Andrew Dunstan [EMAIL PROTECTED] How the heck are we going to document this reasonably? It strikes me as horribly complicated and puzzling for users. The current rule might be an annoyance in porting applications, but it has the advantage of simplicity. If we can somehow make AS optional across the board, then well and good, otherwise I am very dubious about making any change. Ah yes, user's confusion wants to consider a good method so that you may consider, in order to make it avoid. good proposal is desired. P.S) I go out and am no answering for a while. sorry.. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] AS by the syntax of table reference.(8.4 proposal)
- Original Message - From: Tom Lane [EMAIL PROTECTED] Hiroshi Saito [EMAIL PROTECTED] writes: Oops, and, so we really need to support at least ColId as the allowed set of column alias names. (I tried changing the patch to do that, but got a lot of shift/reduce conflicts, some of which are maybe fixable but some seem hard to fix.) Since capability was insufficient, I spent several times as many time as this. It understands the very hard thing. Hardship had left traces upon this features. I want me to still inquire. The case that I couldn't see a good way to fix was the shift/reduce conflicts here: Eh?, c_expr IDENT is no conflicts?_? state 1414 1418 AexprConst: ConstInterval Sconst . opt_interval DAY_P shift, and go to state 1680 HOUR_Pshift, and go to state 1681 MINUTE_P shift, and go to state 1682 MONTH_P shift, and go to state 1683 SECOND_P shift, and go to state 1684 YEAR_Pshift, and go to state 1685 DAY_P [reduce using rule 1149 (opt_interval)] HOUR_P[reduce using rule 1149 (opt_interval)] MINUTE_P [reduce using rule 1149 (opt_interval)] MONTH_P [reduce using rule 1149 (opt_interval)] SECOND_P [reduce using rule 1149 (opt_interval)] YEAR_P[reduce using rule 1149 (opt_interval)] $default reduce using rule 1149 (opt_interval) What this is pointing out is that without AS, this statement is actually ambiguous: SELECT INTERVAL '1 year' YEAR; Is YEAR meant to be a column alias or a qualifier for the interval constant? postgres=# SELECT INTERVAL '1 year' YEAR; interval -- 1 year (1 row) Sorry, please let me read the following sentences later. AFAICS, the only way to resolve that would be to make YEAR, as well as the other interval qualifier words (MONTH etc), not be allowed as a ColId ... which is per SQL spec but I confidently predict howls of anguish from our users if we do it. I imagine there are more than a few tables out there with columns named month, for instance. I guess plan B could be to rip out the special interval-constant syntax, which we have never really implemented anyway. There isn't any functional reason to implement it, it'd just be for spec compliance, and you could certainly argue that supporting no-AS is more interesting than supporting interval-constant qualifiers. The other conflicts I saw could be resolved by making a small number of other keywords like CHARACTER and VARYING reserved (or more reserved than they are now anyway). These seemed like they'd be less of a problem to reserve than the interval qualifier words. However that still leaves us with the problem that c_expr isn't flexible enough to make this spec-compliant. AFAICS the only way to fix that is to give up postfix operators. IMHO, an actual loss of functionality is too high a price to pay for being able to omit AS. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] mklink of pg_standby
Hi. - Original Message - From: Magnus Hagander [EMAIL PROTECTED] Junctions only work for directories, not for files. In theory, you should be able to use mklink to create a hardlink on previous versions of Windows, but I'm not sure if it'll work. But we want symlinks here, not hardlinks, and they are simply not supported on earlier versions of Windows. It is alerady documented that it doesn't work on Windows prior to Vista. I think this is fine. What we could add is a specific version check to pg_standby to have it emit a not supported on this windows version error if it's not supported. But I think that's overkill - it will still fail, and it's well documented that it's not *supposed* to work. Yeah, vote +1:-) Probably, the equipment which is not Symbolic Link is needed in order to correspond to XP and 2K. It is hard to use rather than 'SymbolicLink'. It will be enough if notice are written to a document. 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: [HACKERS] mklink of pg_standby
Hi. From: Magnus Hagander [EMAIL PROTECTED] Yeah, vote +1:-) Probably, the equipment which is not Symbolic Link is needed in order to correspond to XP and 2K. It is hard to use rather than 'SymbolicLink'. It will be enough if notice are written to a document. The notice is *alraedy* in the documentation. http://www.postgresql.org/docs/8.3/static/pgstandby.html has: -l will not work on versions of Windows prior to Vista. Ugaa, sorry this noise. , I had overlooked it. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] mklink of pg_standby
Hi Simon, and Dave,Magnus. About pg_standby, a link option cause a problem in windows(XP and 2k,2k3). It is because the call of mklink is needed. Then, they are the new programs of VISTA and 2008. It is CreateSymbolicLink of API of kernel32.lib is equipped with mklink. http://msdn2.microsoft.com/en-us/library/aa363866.aspx Therefore, I considered whether it should correspond by the 'Junction' or the 'Hard Link' this way and that. However, The addition thought that it was not desirable by the reason of the process of evolution functional pg_standby. A copy function is no problem. However, I think that it is necessary to write it to a document in order to avoid a user's confusion. probably, has that no source code corrects. to Dave,and Magnus. You can do more honest suggestion.:-) Regards, Hiroshi Saito ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Problem of a server gettext message.
Hi. Yeah, As a part from which a problem happens, it is your suggestion. This is only the check. http://winpg.jp/~saito/pg83/message_check/gtext2.c Therefore, a message needed is acquirable in the next operation. gtext2 C UTF-8 http://winpg.jp/~saito/pg83/message_check/codeset_utf8_msg.txt gtext2 C EUC_JP http://winpg.jp/~saito/pg83/message_check/codeset_eucjp_msg.txt However, The check of accuracy is not settled yet. If all server encodings are possible, I will want to work. But but, It is not desirable that more encodings are intermingled as a log message Then, here is no still good method. Furthermore, a good solution plan is desired. probably.. Thanks! Regards, Hiroshi Saito - Original Message - From: Zeugswetter Andreas ADI SD [EMAIL PROTECTED] GetText is conversion po(EUC_JP) to SJIS. Yes. Are you sure about that? Why would gettext be converting to SJIS, when SJIS is nowhere in the environment it can see? gettext is using GetACP () on Windows, wherever that gets it's info from ... chcp did change the GetACP codepage in Hiroshi's example, but chcp does not reflect in LC_* Seems we may want to use bind_textdomain_codeset. Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Problem of a server gettext message.
Hi. I think this has many problems. However, by the reason the release is approaching, this is not the situation which I'm looking at leisurely.. Server message has a problem by 8.3beta4 on windows. The situation is this. 1. initdb -E UTF-8 --no-locale This is C locale. http://winpg.jp/~saito/pg83/postgresql-8.3beta4_info2.png 2. Japanese local message of po file to setting(share/locale/ja) . 3. set the client_encoding is SJIS. http://winpg.jp/~saito/pg83/postgresql-8.3beta4_info1.png 4. action error message is made to send from server. It is crash http://winpg.jp/~saito/pg83/postgresql-8.3beta4_crash.png 5. The reason is because the message which a server outputs is SJIS. http://winpg.jp/~saito/pg83/postgresql-8.3beta4_crash.log Version 8.2.x outputs an English message. It did not look at a problem. Then, I consider as LC_MESSAGE for a server message, or wish a back patch. Is there any good solution method? Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Problem of a server gettext message.
Hi. From: Peter Eisentraut [EMAIL PROTECTED] Am Montag, 10. Dezember 2007 schrieb Hiroshi Saito: Hi Peter-san. It is this. http://winpg.jp/~saito/pg83/ja.zip Sorry, we need the *po* (text) files, not the *mo* (binary) files. Ooops, Although it is an object for Version 8.2.5. http://www.postgresql.jp/wg/jpugdoc/po/postgresql-8-2-5-nls-patch.gz ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Problem of a server gettext message.
Hi Peter-san. Thank you for various. ! - Original Message - From: Peter Eisentraut [EMAIL PROTECTED] Am Montag, 10. Dezember 2007 schrieb Hiroshi Saito: Hi. From: Peter Eisentraut [EMAIL PROTECTED] Am Montag, 10. Dezember 2007 schrieb Hiroshi Saito: Hi Peter-san. It is this. http://winpg.jp/~saito/pg83/ja.zip Sorry, we need the *po* (text) files, not the *mo* (binary) files. Ooops, Although it is an object for Version 8.2.5. http://www.postgresql.jp/wg/jpugdoc/po/postgresql-8-2-5-nls-patch.gz OK, you have PO file in EUC-JP server encoding UTF-8 client encoding SJIS Yes. When the server wants to send an error message to the client, it will convert them from the server to the client encoding. The English messages are ASCII, so this will work, because server encodings are required to be ASCII compatible. The result of the gettext calls, however, is encoded in EUC-JP, so the server will take the EUC-JP bytes and attempt to do a UTF-8 to SJIS conversion on them. This will cause a crash. Probably no. GetText is conversion po(EUC_JP) to SJIS. Then, The stderr output of a server is outputted without an error to log by it. That's right message with it similar to start-up. However, The conversion obstacle of a message is encountered at the time of the conditions returned to a client. Conversion of the step of the following it takes place. 1. iconv(GetText) po(EUC_JP) to SJIS. 2. message to client UTF8(server encoding) to SJIS(client encoding) But, this character that should be UTF-8 is a SJIS message(1.). It causes an error. Therefore, this log is proving. http://winpg.jp/~saito/pg83/postgresql-8.3beta4_crash.log Anyway, the current situation is it although there is a problem.. What you need to do is set the locale to something compatible with the server encoding (e.g., ja_JP.utf8). Then gettext will recode its EUC-JP data to UTF-8 before it is sent to the server. More specifically, you need to set the LC_CTYPE locale category to make this happen. I understand that users in Japanese environments like to keep the LC_COLLATE setting to C, and you should still be able to do that. But without a proper LC_CTYPE setting, this will not work. (That is the explanation for Linux. Windows might be different in the details, but I suspect it has the same mechanisms.) As for message, the current state is not such probably.. It is the problem which arises only by the server with client encoding which can't be used as server encoding. It may be a problem of Japan... If a message text is not used by the server, a problem does not occur. Therefore, It is TODO until it has the margin of time. sorry... I'm very busy now... I am deeply grateful to you for your kindness. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Problem of a server gettext message.
From: Tom Lane [EMAIL PROTECTED] Are you sure about that? Why would gettext be converting to SJIS, when SJIS is nowhere in the environment it can see? I believe that Peter's hypothesis is that gettext is leaving the string in EUC_JP because it sees locale = C and so has no basis for doing any conversion. We still end up with a failure, because the basic problem is that the string isn't UTF8, but it's important to be sure we understand the exact mechanism. Um, It is a simple GetText program. http://winpg.jp/~saito/pg83/message_check/gtext.c for example.. http://winpg.jp/~saito/pg83/message_check/gettext_932.png http://winpg.jp/~saito/pg83/message_check/C_message.txt http://winpg.jp/~saito/pg83/message_check/Non_message.txt http://winpg.jp/~saito/pg83/message_check/UTF8_message.txt http://winpg.jp/~saito/pg83/message_check/Japanese_message.txt All are SJIS outputs. However, chcp 1252 http://winpg.jp/~saito/pg83/message_check/gettext_1252.png 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
[HACKERS] Calculation of a shared memory
Hi. I think that a calculation sheet will be made. However, calculation does not suitable.:-( It is this.(8.2.5 Default-FreeBSD) -- max_locks_per_transaction 64 max_connections 40 max_prepared_transactions 5 shared_buffers 28MB wal_buffers 64kB max_fsm_relations 1000 max_fsm_pages 179200 inet% ipcs -b -m Shared Memory: T ID KEY MODEOWNERGROUP SEGSZ m 917504 5432001 --rw---saitowheel 32571392 40*(400+270*64)= 707200 5*(600+270*64)= 89400 28MB= 29360128 64kB= 65536 1000*70= 7 179200*6= 1075200 Total :31367464 ipcs-m:32571392 -1203928 (difference is large: why?) Table 16-2. Configuration parameters affecting PostgreSQL's shared memory usage http://www.postgresql.org/docs/8.2/static/kernel-resources.html#SYSVIPC It may be the bug of postgres or whether the document is wrong or My misapprehension. Can someone see a near value? Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
