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
Hi Michael,
Isn't it an ODBC issue?
regards,
Hiroshi Inoue
(2014/03/26 15:39), Michael Paquier wrote:
Hi all,
The behavior of rollback when an error occurs on an handle is
controlled by extending Protocol with "$PROTNUM-[0|1|2]" where:
- 0 = let the application handl
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--
(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
(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/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 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/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
>>>>
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/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
(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
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
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
(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
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
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
(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
(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 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
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
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
(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
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
井上です。
ご苦労様です。
このスレッド気になっていたのですが、ようやく少し
余裕ができたのでテストなどしてみました。
Takahiro Itagaki wrote:
> Log Message:
> ---
> PGDLLEXPORT is __declspec (dllexport) only on MSVC,
> but is __declspec (dllimport) on other compilers
私が知る限りdlimportがexportの引きがねになることは
ないのでこの部分にはかなり違和感を感じていました。
実際__declspec(..)をすっ
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
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
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
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
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
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
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
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
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
>
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
) 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
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
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
) 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:
> 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
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&#
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
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
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
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
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
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 -
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
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
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
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
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:
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
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
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
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
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
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
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:
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
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:
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
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
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&
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
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.
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
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
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,
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 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
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
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
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
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.
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
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)
---
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)
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
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:
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
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 ?
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
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
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
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 ?
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
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
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
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:
>>>>> ---
>>
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
ack
to libpq mode once after it went into hi-jacking mode.
As for hi-jacking mode used in the driver it's better to be able to use
encapsulated
recv/send than getting the pointer to SSL or socket.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
work
before 7.4
using V3 protocol, holdable cursors etc. The current driver under Windows is
available without the existence of libpq.
regards,
Hiroshi Inoue
---(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
Stephen Frost wrote:
>* Martijn van Oosterhout (kleptog@svana.org) wrote:
>
>
>>On Thu, Apr 13, 2006 at 08:48:54AM +0100, Dave Page wrote:
>>
>>
>>>Well, we had a pure custom implementation of the protocol, had a pure
>>>libpq based version and after much discussion decided that the best
>>>
t;
In case of SSL mode, the driver gets the communication path using
PQsocket() or PQgetssl() after calling PQconnectdb(). The driver
comunicates with the server by itself using the path. In case of
non-SSL mode, the driver never calls libpq API at all.
regards,
Hiroshi Inoue
--
IL: Cursors must be READ ONLY.
Because we haven't supported updatable cursors yet.
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])
essage is the last response from
the participant to the coordinator. I missed the "OK" message before it.
Where were my eyes ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 3: 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
1 - 100 of 506 matches
Mail list logo
