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 handle rollbacks
- 1 = rollback
provide similar 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 in...@tpf.co.jp 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 libpgeventdll.def.
http
(2014/02/12 15:31), Inoue, Hiroshi wrote:
(2014/02/12 3:03), Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp 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 dllwrap. But I agree this is worth trying for Mingw
(2014/02/15 11:42), Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp 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
see on my old machine.
Hmm
(2014/02/15 2:32), Tom Lane wrote:
I wrote:
Hiroshi Inoue in...@tpf.co.jp 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 trying?
I hadn't noticed that part of plpython's
(2014/02/12 8:30), Tom Lane wrote:
I wrote:
Hiroshi Inoue in...@tpf.co.jp 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 Makefile.shlib was making
my head hurt
(2014/02/15 2:32), Tom Lane wrote:
I wrote:
Hiroshi Inoue in...@tpf.co.jp 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 trying?
I hadn't noticed that part of plpython's
(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 in...@tpf.co.jp writes:
I tried MINGW port with the attached change and successfully built
src and contrib and all pararell regression tests were OK
(2014/02/12 12:28), Inoue, Hiroshi wrote:
(2014/02/12 8:30), Tom Lane wrote:
I wrote:
Hiroshi Inoue in...@tpf.co.jp 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
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.
regards,
Hiroshi Inoue
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
(2014/02/09 8:06), Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp 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
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
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 cr...@2ndquadrant.com writes:
On 02/05/2014 06:29 AM, Tom Lane wrote:
I had been okay with the manual PGDLLIMPORT
,
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
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 (pgsql-hackers@postgresql.org
(2013/07/20 1:11), Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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 dicey situations if you
use currtid_
(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 VC8)
setlocale(LC_, Chinese
locale name?
Unfortunately I don't know any explanation how dots are allowed.
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 VC8)
setlocale(LC_, Chinese
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 it any time
soon, it's been
right, unescaped
quotes can only
* appear in pairs, so there should be another
character.
*/
regards,
Hiroshi Inoue
I don't know where the
problem really comes from, but I doubt the connection you're trying to
make above
(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 script are substituted by actual values
using
.
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
--- port.h 2011-01-23 21
-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 __declspec (dllimport)
#endWindows 7
time. Is it fixed with gcc 4.5?
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
井上です。
ご苦労様です。
このスレッド気になっていたのですが、ようやく少し
余裕ができたのでテストなどしてみました。
Takahiro Itagaki wrote:
Log Message:
---
PGDLLEXPORT is __declspec (dllexport) only on MSVC,
but is __declspec (dllimport) on other compilers
私が知る限りdlimportがexportの引きがねになることは
ないのでこの部分にはかなり違和感を感じていました。
,
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
LC_CTYPE 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
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
Dave Page wrote:
On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue in...@tpf.co.jp 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
, 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 mag...@hagander.net wrote:
2009/12/31 Hiroshi Inoue in...@tpf.co.jp:
Magnus Hagander wrote:
2009/12/30 Hiroshi Inoue in...@tpf.co.jp:
Hi,
As far as I tested, the krb_server_keyfile setting
in postgres.conf doesn't work
.
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
--- auth.c 30 Dec 2009 15:03
Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp 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
case.
Don't we already have something like
Magnus Hagander wrote:
2009/12/30 Hiroshi Inoue in...@tpf.co.jp:
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_KTNAME
) 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.
regards,
Hiroshi Inoue
Index: Solution.pm
Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp 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 thought about this some more, and I wonder why
Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp 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 current CVS.
It uses a similar way like LC_TIME
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
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's
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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_open().
The problem
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 message catalog to contain Japanese kanji characters.
regards,
Hiroshi Inoue
--
Sent via pgsql-hackers
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp 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
,
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
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 - 1.78
? 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 subscription:
http
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
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
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
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 attached one
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 changes
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
cache_locale_time() 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
--
Sent
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 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
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 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
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
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
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
Tom Lane wrote:
Hiroshi Inoue in...@tpf.co.jp 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 implies an encoding
char_length(upper(:jpnstr));
char_length
-
4
(1 行)
regards,
Hiroshi Inoue
Index: formatting.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/formatting.c,v
retrieving revision 1.151
diff -c -c
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 languages/countires where
(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, .20932) instead and you
would get
井上です。
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
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 special locale
handling for UTF8 that doesn't change the full environment
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 EUC_JP and a conversion between
Shitt_jis and EUC_JP is necessarily
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 failure to distinguish CP932 from CP20932. Is that correct?
I'm
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)
UPDATE 1
be
(seesion-2)
UPDATE 0
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 them.
regards,
Hiroshi Inoue
---(end of broadcast
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. I'm suspicious if UPDATABLE VIEWS can be implemented
using the rule system.
regards,
Hiroshi
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)
Filter: (dt = 'a'::text)
(6 rows)
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 1: if posting/reading through
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 problem to
include copy of BSD licensed code as a part
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:
snip
Of course, the developer who owns the LGPL-licensed copyright is free to
relicense his work under
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 ?
I am
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
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,
HIroshi Inoue
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 X, you write
to
person X. That rule
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:
---
Put Autotools-generated files into subdirectory config/; add macro
files used from PostgreSQL
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
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-committes and pgsql-hackers also.
Please note
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 is. My
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 ?
I am
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
then the package is still entirely LGPL
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 PostgreSQL there so you don't need a PostgreSQL
source tree to bootstrap the code.
snip
Added
to SSL or socket.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
for
the current
dependency relation. As for SSL mode it is only a mere extra for the current
enhanced driver. My main purpose was to finish up my unfinished work
before 7.4
using V3 protocol, holdable cursors etc. The current driver under Windows is
available without the existence of libpq.
regards,
Hiroshi
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
version of all
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
---(end of broadcast)---
TIP 6
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])
(Bmuch allowance if we only adopt XA-based protocol.
(B
(Bregards,
(BHiroshi Inoue
(Bhttp://www.geocities.jp/inocchichichi/psqlodbc/
(B
(BTom Lane wrote:
(B
(B Hiroshi Inoue [EMAIL PROTECTED] writes:
(B The simplest senario(though there could be varations) is
(B
(B
1 - 100 of 435 matches
Mail list logo
