n with a clear understanding of why the newer toolchains
> are failing to report a link problem, and yet not building working
> executables.
Is it a linkage error?
Could you please show me the error message concretely?
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
MINGW port to
follow it?
Changing the machine from the one using gcc 3.4.5 to another one
using 4.6.1 also fixes the problem.
regards,
Hiroshi Inoue
(2014/02/07 12:25), Hiroshi Inoue wrote:
> (2014/02/05 14:52), Tom Lane wrote:
>> Craig Ringer writes:
>>> On 02/05/2014 06:29 A
(2014/02/09 8:06), Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool now. Isn
(2014/02/12 12:28), Inoue, Hiroshi wrote:
> (2014/02/12 8:30), Tom Lane wrote:
>> I wrote:
>>> Hiroshi Inoue writes:
>>>> I tried MINGW port with the attached change and successfully built
>>>> src and contrib and all pararell regression tests were
it'd help us even if they fixed it tomorrow. We're going to have
> to be able to build with existing Python distributions for a long time
> to come.
Though the comment in src/pl/plpython/Makefile refers to it, I see
libpython27.a in Python27. I can't find it in Python25.
rega
(2014/02/13 9:51), Hiroshi Inoue wrote:
> (2014/02/12 12:28), Inoue, Hiroshi wrote:
>> (2014/02/12 8:30), Tom Lane wrote:
>>> I wrote:
>>>> Hiroshi Inoue writes:
>>>>> I tried MINGW port with the attached change and successfully built
>>>>
(2014/02/12 8:30), Tom Lane wrote:
> I wrote:
>> Hiroshi Inoue writes:
>>> I tried MINGW port with the attached change and successfully built
>>> src and contrib and all pararell regression tests were OK.
>
>> I cleaned this up a bit (the if-nesting in Makef
(2014/02/15 2:32), Tom Lane wrote:
> I wrote:
>> Hiroshi Inoue writes:
>>> One thing I'm wondering about is that plperl is linking perlxx.lib
>>> not libperlxx.a. I made a patch following plpython and it also
>>> works here.
>>> Is it worth tryi
(2014/02/15 11:42), Tom Lane wrote:
> Hiroshi Inoue writes:
>> (2014/02/15 2:32), Tom Lane wrote:
>>> (BTW, narwhal is evidently not trying to build plpython. I wonder
>>> why not?)
>
>> Due to *initializer element is not constant* error which also can be
(2014/02/15 2:32), Tom Lane wrote:
> I wrote:
>> Hiroshi Inoue writes:
>>> One thing I'm wondering about is that plperl is linking perlxx.lib
>>> not libperlxx.a. I made a patch following plpython and it also
>>> works here.
>>> Is it worth tryi
(2014/02/12 15:31), Inoue, Hiroshi wrote:
> (2014/02/12 3:03), Tom Lane wrote:
>> Hiroshi Inoue writes:
>>> (2014/02/09 8:06), Andrew Dunstan wrote:
>>>> Yeah. Incidentally, we didn't quite get rid of dlltool for Cygwin. We
>>>> did get rid of dllw
(2014/02/20 10:32), Tom Lane wrote:
> Hiroshi Inoue writes:
>> Attached is a patch to remove dllwarp from pgevent/Makefile.
>
> Actually, it looks like this patch doesn't work at all:
Strangely enough it works here though I see double EXPORTS lines
in libpge
ilar patches for pltcl
and plpython.
regards,
Hiroshi Inoue
diff --git a/src/pl/plperl/GNUmakefile b/src/pl/plperl/GNUmakefile
index 1e800a3..55fe9b9 100644
--- a/src/pl/plperl/GNUmakefile
+++ b/src/pl/plperl/GNUmakefile
@@ -36,23 +36,17 @@ DATA = plperl.control plperl--1.0.sql plperl--
ombination with OIDs.
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
g man, I'd
bet that they are used in contexts where the difference between
SnapshotNow and SnapshotSelf wouldn't matter there, either.
Using SnapshotSelf instead of SnapshotNow for currtid_ () wouldn't
matter.
regards,
Hiroshi Inoue
--
Sent via pgsql-hackers mailing list (pgs
(2013/07/20 1:11), Tom Lane wrote:
> Andres Freund writes:
>> On 2013-07-20 00:49:11 +0900, Hiroshi Inoue wrote:
>>> Using SnapshotSelf instead of SnapshotNow for currtid_ () wouldn't
>>> matter.
>
>> I think it actually might. You could get into dic
ows XP. However MSBuildProject.pm seems to specify v120 (or v110) as
the PlarformToolset property. Is it intentional?
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
Bruce Momjian wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Where are we on this issue?
Oops I forgot it completely.
I have a little improved version and would post it tonight.
Ah, very good. Thanks.
Attached is an
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Where are we on this issue?
Oops I forgot it completely.
I have a little improved version and would post it tonight.
Ah
and LC_MONETARY.
A patch attached for the above straightforwardly. Does this work?
I have 2 questions about this patch.
1. How does it work when LC_MONETARY and LC_NUMERIC are different?
2. Calling db_encoding_strdup() for lconv->grouping is appropriate?
regards,
Hiroshi Inoue
Note that #ifdef
do both for time? Is there any value
to that?
Unfortunately wcsftime() is a halfway conveniece function which uses
ANSI version of functionalities internally.
AFAIC the only way to remove the dependency to LC_CTYPE is to call
GeLocaleInfoW() directly.
regards,
Hiroshi Inoue
--
Sent via pgsql
ostgresql.org/pgsql-committers/2010-05/msg00338.php
in the case __GNUC__ >=4?
regards,
Hiroshi Inoue
I wonder why mingw gcc< 4.5 can build codes without the fix...
*** a/src/include/port/win32.h
--- b/src/include/port/win32.h
***
*** 58,64
#define PGDLLIMPORT __declspe
(2010/11/02 8:31), Itagaki Takahiro wrote:
On Tue, Nov 2, 2010 at 6:02 AM, Hiroshi Inoue wrote:
1. warning: '' redeclared without dllimport attribute:
previous dllimport ignored
Is it safe to put back the patch you applied in
http://archives.postgresql.org/pgsql-committers/2010-0
As the bug reporter mentions, initdb loses the single quote in reality.
Concretely speaking, scanstr() called from bootscanner.l loses it.
I'm not sure if it's suitable for the bootstrap code to call scanstr().
regards,
Hiroshi Inoue
> There isn't much hope of Microsoft fixing
(2011/04/20 9:22), Tom Lane wrote:
> Hiroshi Inoue writes:
>> (2011/04/16 2:56), Heikki Linnakangas wrote:
>>> setlocale() on Windows doesn't work correctly if the locale name contains
>>> apostrophes or dots.
>
>> As for apostrophes, isn't the
(2011/04/20 12:25), Andrew Dunstan wrote:
>
> On 04/19/2011 09:42 PM, Hiroshi Inoue wrote:
>>
>> bootstrap_template1() in initdb runs the BKI script in bootstrap
>> mode to create template1. Some symbols (LC_COLLATE, LC_CTYPE in
>> pg_database etc) in the BKI sc
(2011/04/20 15:30), Heikki Linnakangas wrote:
> On 20.04.2011 06:48, Hiroshi Inoue wrote:
>> I can find no concrete reference to problems about locale
>>names containing dots. Is the following an example?
>
> Yes.
>
>> In my environment (Windows Vista using VC
(2011/04/20 22:08), Tom Lane wrote:
> Hiroshi Inoue writes:
>> In my environment (Windows Vista using VC8)
>
>>setlocale(LC_, "Chinese (Traditional)_MCO.950");
>> works and
>>setlocale(LC_, NULL);
>> returns
>>Chinese (
(2011/04/20 15:30), Heikki Linnakangas wrote:
> On 20.04.2011 06:48, Hiroshi Inoue wrote:
>> I can find no concrete reference to problems about locale
>>names containing dots. Is the following an example?
>
> Yes.
>
>> In my environment (Windows Vista using VC
programs link.
Unfortunately locale-aware functions like printf() calls
in main programs would see "C" locales not the locales set
by libintl_setlocale().
Attached is a patch to disable the macro on Windows.
regards,
Hiroshi Inoue
*** port.h.orig 2011-01-15 05:29:13.43600 +0900
井上です。
ご苦労様です。
このスレッド気になっていたのですが、ようやく少し
余裕ができたのでテストなどしてみました。
Takahiro Itagaki wrote:
> Log Message:
> ---
> PGDLLEXPORT is __declspec (dllexport) only on MSVC,
> but is __declspec (dllimport) on other compilers
私が知る限りdlimportがexportの引きがねになることは
ないのでこの部分にはかなり違和感を感じていました。
実際__declspec(..)をすっ
Peter Eisentraut wrote:
> Hiroshi Inoue wrote:
>> Hiroshi Inoue wrote:
>>> User Petere wrote:
>>>> Log Message:
>>>> ---
>>>> Put Autotools-generated files into subdirectory config/; add macro
>>>> files used from P
I've not seen your reply yet.
Do you have a mind to cooperate with us ?
I wrote:
> Peter Eisentraut wrote:
>> Hiroshi Inoue wrote:
>>> Hiroshi Inoue wrote:
>>>> User Petere wrote:
>>>>> Log Message:
>>>>> ---
>>
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
Thanks a lot.
Hiroshi Inoue
Jim Nasby wrote:
On May 6, 2007, at 4:38 PM, Hiroshi Inoue wrote:
Under what license is
Peter Eisentraut wrote:
> Hiroshi Inoue wrote:
>> I've not seen your reply yet.
>
> You keep sending your emails to randomly invented addresses, so I don't
> get them.
Must I mail them directly to you in the first place ?
I'm sending the emails to pgsql-committ
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
I am having difficulty in understanding what the problem i
Joshua D. Drake wrote:
Hiroshi Inoue wrote:
Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> Could someone confirm the following my recognition ?
>
>> The LPGL package could add and release a copy of some Postgres BSD
>> licensed code as LGPL ones together with the current LGPL code and
Peter Eisentraut wrote:
> Am Dienstag, 8. Mai 2007 01:45 schrieb Hiroshi Inoue:
>> Must I mail them directly to you in the first place ?
>
> Yes.
Oh I seem to have been apart from the community too long.
Could you please tell me where I can find the rule ?
regards
Peter Eisentraut wrote:
> Am Dienstag, 8. Mai 2007 15:12 schrieb Hiroshi Inoue:
>> Oh I seem to have been apart from the community too long.
>> Could you please tell me where I can find the rule ?
>
> The only "rule" there is is that if you want to talk to person
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
Alvaro Herrera wrote:
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> Robert Treat wrote:
>>> It's generally a very bad idea for a BSD licensed project to include lgpl
>>> licensed code
>
>> Psqlodbc package is LGPL licensed and seems to have little probl
Alvaro Herrera wrote:
Hiroshi Inoue wrote:
Alvaro Herrera wrote:
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Of course, the developer who owns the LGPL-licensed copyright is free to
relicense his work under a
---
Hash Join (cost=24.57..50.59 rows=6 width=10)
Hash Cond: (public.test.id = public.test.id)
-> Seq Scan on test (cost=0.00..21.60 rows=1160 width=10)
-> Hash (cost=24.50..24.50 rows=6 width=4)
-> Seq Scan on test (cost=0.00..24.50 rows=6 width=4)
Heikki Linnakangas wrote:
> Hiroshi Inoue wrote:
>> Concurrently updating an updatable view seems to cause
>> an unexpected result. Is it a known issue?
>
> Looks right to me. What did you expect?
Shouldn't the last response
(session-2)
t's a problem with
re-checking clauses involving subqueries or joins I'd guess.
I don't understand the PostgreSQL specific *FROM* clause correctly.
Currently the relations in the *FROM* clause seem to be read only
and UPDATE operations seem to acquire no tuple level lock on
ting this correctly is a task for future work."
I think there should be a big, fat warning that self-referential
updates have highly non-obvious behaviour in read-committed mode,
and should be avoided.
It seems pretty difficult for PostgreSQL rule system to avoid such
kind of updates.
) Visual C++ Project Builder - コマンド ライン バージョン
8.00.50727
The "Command Line Version" part is localized.
In addtion there's no space between "Mircrosoft" and "(R)".
The attahced patch fixes the error in my environment.
regard
e problem in my test
case.
regards,
Hiroshi Inoue
Index: auth.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.188
diff -c -r1.188 auth.c
*** auth.c 12 Dec 2009 21:35:21 - 1.188
--- a
Tom Lane wrote:
> Hiroshi Inoue writes:
>> Because gssapi32.dll(krb5_32.dll) seems to call
>> getenv("KRB5_KTNAME") in msvcr71, postgres.exe
>> should call putenv("KRB5_KTNAME=...") in msvcr71.
>> The attached patch fixes the problem in my test
>
Magnus Hagander wrote:
2009/12/30 Hiroshi Inoue :
Hi,
As far as I tested, the krb_server_keyfile setting
in postgres.conf doesn't work on Windows.
Because gssapi32.dll(krb5_32.dll) seems to call
getenv("KRB5_KTNAME") in msvcr71, postgres.exe
should call putenv("KRB5_KTN
Magnus Hagander wrote:
On Thu, Dec 31, 2009 at 00:57, Magnus Hagander wrote:
2009/12/31 Hiroshi Inoue :
Magnus Hagander wrote:
2009/12/30 Hiroshi Inoue :
Hi,
As far as I tested, the krb_server_keyfile setting
in postgres.conf doesn't work on Windows.
Because gssapi32.dll(krb5_3
one have the same name?
If so, where will they be installed?
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
Dave Page wrote:
On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue wrote:
Maybe I'm missing the point and have a question.
For example, do 32bit psql and the 64bit one have the same name?
If so, where will they be installed?
I'm only talking about libpq. I see no reason to have 3
Magnus Hagander wrote:
> Hiroshi Inoue wrote:
>> Hi Magnus and all,
>>
>> Magnus Hagander wrote:
>>> Log Message:
>>> ---
>>> Explicitly bind gettext() to the UTF8 locale when in use.
>>> This is required on Windows due to the spe
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Hiroshi Inoue wrote:
>>> because Shift_JIS isn't allowed as a server encoding. So
>>> the Japanese Windows native message encoding Shift_JIS never
>>> matches the server encoding EU
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I'm not following this either. If the patch is really necessary then it
>>> seems it must be working around a bug in the Windows version of gettext,
>>> ie fail
井上です。
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 atta
C++2008 at least (and the bug is fixed there).
Please call setlocale(LC_CTYPE/LC_ALL, "") first.
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
ITAGAKI Takahiro wrote:
Hiroshi Inoue <[EMAIL PROTECTED]> wrote:
Please call setlocale(LC_CTYPE/LC_ALL, "") first.
Ah, it works! But setlocale(*, "") means that we always use platform
locale (Japanese and SJIS in Japan).
Maybe you can call setlocale(LC_CTYPE,
Magnus Hagander wrote:
On 25 nov 2008, at 05.00, Tom Lane <[EMAIL PROTECTED]> wrote:
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
If that's true then this code is presently broken for *every* locale
under Windows, not only Japanese.
Maybe there are a few la
Magnus Hagander wrote:
Hiroshi Inoue wrote:
I think the thing us that as long as the encodings are compatible
(latin1 with different names for example) it worked fine.
In any case I think the problem is that gettext is
looking at a setting that is not what we are looking at. Particularly
r
--
カタカナ
(1 行)
inoue=# select char_length(upper(:jpnstr));
char_length
---------
4
(1 行)
regards,
Hiroshi Inoue
Index: formatting.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/formatting.
Tom Lane wrote:
> Hiroshi Inoue writes:
>> Upper(), lower() or initcap() function truncates the result
>> under Japanese Windows with e.g. the server encoding=UTF-8
>> and the LC_CTYPE setting Japanese_japan.932 .
>
> Hmm, I guess that makes sense, since the LC_CTYPE
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 writes:
Thomas H. wrote:
so at least that explains the "changed&
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 writes:
Tho
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
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
ITAGAKI Takahiro wrote:
Hiroshi Inoue 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
Magnus Hagander wrote:
Hiroshi Inoue wrote:
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.
Yes, I think
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
Hiroshi Inoue 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
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
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
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Do you want to send an updated patch for it, or do you want me to look
at it?
I would send a new patch to which I added a simple ISO style check for
locale names.
Attached is a new patch.
I added a simple ISO style locale name check.
Avoided
ime() is rarely called (at most once per LC_TIME change).
The function cache_locale_time() calls strftime() only 38(=7*2+12*2)
times. Now I fundamentally agree with Itagaki-san's patch. Though
it may not be the most effective code, it looks like the clearest one.
regards,
Hiroshi Inoue
--
Se
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
*set lc_messages does not work* issue isn't directly related to this
issue.
regards,
Hiroshi Inoue
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
*set lc_messages does not work* issue isn't directly related to this
issue.
Though I'm not sure how we can test it, I can provide test results
like the at
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
In what way should it be changed?
One is already committed by you.
[COMMITTERS] pgsql: Use the new text domain names
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Do you want to send an updated patch for it, or do you want me to look
at it?
I would send a new patch to which I added a simple ISO style check for
locale names.
Attached is a new patch.
I added a
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
There still needs to be some error checking added in IsoLocaleName(),
but this is a start.
Can someone please test this? :-)
OK I would check it tonight.
Thanks.
OK seems to works here.
The attached is a test case using
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
In what way should it be changed?
One is already committed by you.
[COMMITTERS] pgsql: Use the
Yes, that would be much better.
Something like this then?
It seems OK to me.
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
irst
place? My original patch doesn't contain SetEnvironmentVariable call
in pg_unsetenv() because _putenv() seems to call SetEnvironmentVariable
internally.
regards,
Hiroshi Inoue
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
gards,
Hiroshi Inoue
Index: backend/utils/mb/mbutils.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/mb/mbutils.c,v
retrieving revision 1.78
diff -c -r1.78 mbutils.c
*** backend/utils/mb/mbutils.c 22 Jan 2009 10:09:48 -
we had better
simply call it for char2wchar().
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
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Maybe use a special string "Translate Me First" that
doesn't actually need to be end-user-visible, just so no one sweats
over
getting it right in context.
Yep, something like that. There seems to be a mag
Tom Lane wrote:
Hiroshi Inoue writes:
Heikki Linnakangas wrote:
I just tried that, and it seems that gettext() does transliteration, so
any characters that have no counterpart in the database encoding will be
replaced with something similar, or question marks.
It doesn't occur i
Windows.
First any combination of valid lc_messages and non-existent encoding
passes the test strcmp(gettext(""), "") != 0 .
Second for example the combination of ja(lc_messages) and ISO-8859-1
passes the the test but the test fails after I changed the last_trans
lator part of ja me
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Maybe use a special string "Translate Me First" that
doesn't actually need to be end-user-visible, just so no one sweats
over
getting it right in context.
Yep, some
Heikki Linnakangas wrote:
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
I just tried that, and it seems that gettext() does transliteration,
so any characters that have no counterpart in the database encoding
will be replaced with something similar, or question marks. Assuming
that&#
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Hiroshi Inoue wrote:
>>> What is wrong with checking if the codeset is valid using iconv_open()?
>
>> That would probably work as well. We'd have to decide what we'd try to
>> convert from with iconv_o
) based, it seems
natural to convert the file name to wide characters once.
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
Tom Lane wrote:
> Hiroshi Inoue writes:
>> Tom Lane wrote:
>>> I think what this suggests is that there probably needs to be some
>>> encoding conversion logic near the places we examine localeconv()
>>> output.
>
>> Attached is a patch to the curre
Tom Lane wrote:
> Hiroshi Inoue writes:
>> Tom Lane wrote:
>>> * This seems to be assuming that the user has set LC_MONETARY and
>>> LC_NUMERIC the same. What if they're different?
>
>> Strictky speaking they should be handled individually.
>
> I
PARE/EXECUTE ?
What about Karel's work ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Christopher Kings-Lynne wrote:
> > >
> I think that is why Tom was suggesting making all the column values NULL
> and removing the pg_attribute row for the column. With a NULL value, it
> doesn't take up
Fernando Nasser wrote:
>
> Hiroshi Inoue wrote:
> >
> > Fernando Nasser wrote:
> > >
> > > As most things in the SQL standard, you have to collect information
> > > from several places and add it together.
> > >
> > > Look at 4.2
olumn numbers instead. Certainly it makes RENAME happy
but DROP COLUMN unhappy. If there's a foreign key a_rel/1/3
and the second column of the relation is dropped the
parameter must be changed to be a_rel/1/2. If neither
foreign key stuff nor DROP COLUMN take the oth
ing attisdropped field. What
I meant to say is that the differene is very small.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
schema need be qualified only if they
What does the current schema mean ?
Or What does "local" mean ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
of a transaction to go
> irregardless then it shouldn't be within the transaction.
Oops is this issue still living ?
I object to the TODO(why ) strongly.
Please remove it from the TODO first and put it back
to the neutral position.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/
1 - 100 of 506 matches
Mail list logo
