Re: [HACKERS] COPY foo FROM STDOUT and ecpg

was added because the check for COPY FROM STDIN had to added anyway. Since you left that one in, the patch is fine by me, although I still don't see a reason for it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes

Re: [HACKERS] [PATCH]Fix for ecpglib's native language messages output

the problem, patch committed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux

Re: [HACKERS] pkg-config files for libpq and ecpg

checking. libecpg_compat doesn't directly need libpq IIRC, but it does indirectly There are a couple functions from libecpg that are used in libecpg_compat and libecpg itself does need libpq. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael

Re: [HACKERS] [PATCH] Patch to fix libecpg.so for isinf missing

refer to the attachment ecpglib-Makefile.patch. Thanks for finding and fixing the problem, patch committed to HEAD and all 9.* branches. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql

Re: [HACKERS] [PATCH] Patch to fix libecpg.so for isinf missing

that upush didn't work correctly. Sorry. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux

Re: [HACKERS] Patch to fix ecpg core dump with nested structure pointer variable

I have bumped in the segmentation fault in ecpg when using pointer to nested structure variable. ... Please see the attached patch for the fix and test case to reproduce the scenario. Thanks for spotting and fixing this. Patch committed to git. Michael -- Michael Meskes Michael at Fam

Re: [HACKERS] fix ecpg core dump when there's a very long struct variable name in .pgc file

On Sun, Nov 25, 2012 at 08:02:33PM +0800, Chen Huajun wrote: Thanks for your comment,I will add the patch into commitfest later. No need for that, the patch is already committed to the archive. It maybe my first patch for open source. It definitely is then. Michael -- Michael Meskes Michael

Re: [HACKERS] fix ecpg core dump when there's a very long struct variable name in .pgc file

that this is better be fixed and cjust committed the second version of your patch. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL

Re: [HACKERS] Issue in Behavior of Interval Datatype

, too. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL - Sent

Re: [HACKERS] ECPG FETCH readahead

, better to find it now instead of after release. Anyway, I moved the patch to 2012-next (I hope I did it correctly) so 2012-1 can be closed. Let's try to get this patch done in the next commit fest. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael

Re: [HACKERS] ECPG FETCH readahead

should always be a FETCH N, no matter what, i.e. if the readahead window is larger, use it, but even if it's smaller we should still fetch N at the same time. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes

Re: [HACKERS] ECPG FETCH readahead

, but please make it work like what you suggested to make sure people don't have to recompile. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot

Re: [HACKERS] ECPG FETCH readahead

to increase the window size accordingly if you want so as a programmer. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força

Re: [HACKERS] ECPG FETCH readahead

and remove performance. Why is that? I'm interested in what others think, but to me that sounds like a show-stopper. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes

Re: [HACKERS] disposition of remaining patches

On Tue, Apr 10, 2012 at 09:40:58AM -0400, Robert Haas wrote: ECPG FETCH readahead - Michael Meskes is going to commit this soon; everyone seems to agree it's ready to go. It still needs a couple minor tweaks but I think it will be done shortly. Michael -- Michael Meskes Michael at Fam-Meskes

Re: [HACKERS] ECPG FETCH readahead

. ECPGopen() will need an extra bool argument to distinguish this. Is this acceptable? Noah, Michael? Sounds perfect. Fine by me. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot

Re: [HACKERS] ECPG FETCH readahead

? I'm fine with whatever is easier for you. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use

Re: [HACKERS] ECPG FETCH readahead

if -R changes something in the compiler stage. The test case cursor-readahead.pgc has a comment saying test automatic prepare for all statements. Copy/Paste error? I cannot find a test that tests the environment variable giving the fetch size. Could you please point me to that? Michael -- Michael

Re: [HACKERS] ECPG FETCH readahead

check simply runs pg_regress once which uses its own configuration file that doesn't have a way to set or unset an environment variable. This could be a useful extension to pg_regress though. How about calling setenv() from the test program itself? Michael -- Michael Meskes Michael at Fam

Re: [HACKERS] ECPG FETCH readahead

this patch as ready for committer. That second patch seems to apply cleanly after the first one got applied. Now, which one was reviewed and is considered ready for commit? The first one? Or both? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org

Re: [HACKERS] Last gasp

On Thu, Apr 05, 2012 at 02:23:03PM -0400, Tom Lane wrote: I think the ECPG fetch patch is about ready to go. Normally Michael Meskes handles all ECPG patches, but I'm not sure what his schedule is like. I'm not sure what the politics are of someone else touching that code. I think we

Re: [HACKERS] ECPG FETCH readahead

is an acceptable level of muddle to provide this aid. A DECLARE CURSOR syntax extension goes too far. +1 from me. Let's not add special ecpg sql syntax if we don't absolutely have to. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael

Re: [HACKERS] ecpg.sgml: the the - the

On Sun, Mar 11, 2012 at 11:25:01AM +0100, Erik Rijkers wrote: ecpg.sgml: the the - the Fixed, thanks for spotting this. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber

Re: [HACKERS] ECPG FETCH readahead

-- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing

Re: [HACKERS] ECPG FETCH readahead

a normal programmer would expect only one row being transfered when fetching one. Other than that, thanks for the great review. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org

Re: [HACKERS] ecpglib use PQconnectdbParams

and in particular these emails: http://archives.postgresql.org/pgsql-hackers/2006-08/msg00118.php http://archives.postgresql.org/pgsql-hackers/2006-08/msg00134.php Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian

Re: [HACKERS] ecpglib use PQconnectdbParams

used to work without the patch and besides the error message is not really telling in this context. So if anyone is interested in looking at this fine, if not I will as soon as I find some spare time. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org

Re: [HACKERS] ecpglib use PQconnectdbParams

On Thu, Feb 02, 2012 at 08:01:48PM +0200, Peter Eisentraut wrote: I noticed ecpglib still uses PQconnectdb() with a craftily assembled connection string. Here is a patch to use PQconnectdbParams() instead. Thanks, committed. Will sync as soon as I'm online again. Michael -- Michael Meskes

Re: [HACKERS] SQLDA fix for ECPG

and dataset. The DECIMAL struct is safe because the digits[] array is embedded there. ... Applied, thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes

Re: [HACKERS] Notes on implementing URI syntax for libpq

be there in the archive, not sure though if the old code fits the requirements for this feature completely. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot

Re: [HACKERS] SQLDA fix for ECPG

On Mon, Nov 14, 2011 at 09:06:30AM +0100, Boszormenyi Zoltan wrote: Yes, you are right. For timestamp and interval, the safe alignment is int64. Patch is attached. Applied, thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael

Re: [HACKERS] SQLDA fix for ECPG

This must have been a cut and paste bug and is incorrect in 9.0.x, 9.1.x and GIT HEAD. It would be nice to have it applied before the next point releases come out. Applied, thanks for the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org

[HACKERS] Re: [COMMITTERS] pgsql: Made ecpglib write double with a precision of 15 digits.

On Mon, Jul 18, 2011 at 12:16:50PM -0400, Tom Lane wrote: ... not to mention that the buildfarm is now failing ecpg-check everywhere ... I seem to have messed up my local make check call, sorry, working on the fix. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.

still have the translations in the source tree in the main git. At least this is how I think it works. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.

are built in order to use that. Ah, good point. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers

[HACKERS] Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.

On Mon, Jun 20, 2011 at 03:03:37PM +0300, Devrim GÜNDÜZ wrote: On Mon, 2011-06-20 at 11:58 +, Michael Meskes wrote: Fixed string in German translation that causes segfault. Applied patch by Christoph Berg c...@df7cb.de to replace placeholder %s by correct string. AFAIK

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.

On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote: Yep. Peter overrides them just before each release. Aren't there better ways to implement this, like git submodules? This redundancy seem awkward to me. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: [HACKERS] ECPG parse.pl and parse2.pl

. But with 9.1 being so close, there's no need for the old script anymore. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia

Re: [HACKERS] unknown conversion %m

On Thu, Apr 28, 2011 at 02:49:07PM -0400, Andrew Dunstan wrote: I'll make that change if Michael's happy. Sure, go ahead. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org

Re: [HACKERS] unknown conversion %m

I'll make that change if Michael's happy. Sure, go ahead. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Windows 64 bit warnings

explanation what should be stored in sqlformat. be used anywhere, and the comment on the field says it for future Gosh, I didn't know that our own source says it's reserved for future use. I guess that makes removing the statement even more of an option. Michael -- Michael Meskes Michael at Fam

Re: [HACKERS] Windows 64 bit warnings

there, while a long is only 4. But if we really want to store the result from PQfformat() in it, why is it a char * at all? Zoltan, did you see this? Given that you wrote the code it might be good if you could comment on this. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

commit it to the archive so we can see if it breaks anything. The old script is still in there so in case of a major problem that I cannot foresee we can simply change the Makefile back to using parse.pl. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net

Re: [HACKERS] ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname

Did this ever get applied? If so, I can't find it. No, my bad, I simply forgot about it, sorry. Will work on this now. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber

Re: [HACKERS] Re: ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname

, so everyone can test it, but your test case works just nicely on my system. No idea why your results are different. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

was written in awk and then translated to perl by a2p. We knew that this code was less than optimal, but at least it works. As I already said when the script was introduced, I would love to have a real perl solution, but I'm not a perl programmer by any means. Michael -- Michael Meskes Michael at Fam

Re: [HACKERS] Perl 5.12 complains about ecpg parser-hacking scripts

On Sun, Jan 23, 2011 at 09:16:33AM -0600, Andy Colson wrote: Are there other problems with this script? Does it not pull out the rule names correct all the time or something? What problem was Matt having with it? No, afaict it works correctly but throws some warnings. Michael -- Michael

Re: [HACKERS] ECPG question about PREPARE and EXECUTE

with these and then it simply wasn't implemented when we went to server side prepares, that is if my memory serves well. The same feature is implemented for cursor declaration/open I think. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael

Re: [HACKERS] Comparison with true in source code

/ecpg.c(327): ptr2ext[1] = (header_mode == true) ? 'h' : 'c'; I actually see no reason why these variables are not defined as bool instead of int, so I changed this. Hopefully I found all of them. Michael -- Michael Meskes Michael at Fam-Meskes dot De

[HACKERS] Re: [BUGS] rollback to savepoint leads to transaction already in progress

. As reported, it worked for ecpg (PostgreSQL 8.3.8) 4.4.1. You seem to be answering to an email that I didn't see and couldn't find in the archive either. Was it send in private or to the list? If it went to the list I might be lagging behind. Michael -- Michael Meskes Michael at Fam-Meskes dot

Re: [HACKERS] Report: removing the inconsistencies in our CVS-git conversion

forget about it. All changes to the parser went into CVS HEAD as soon as a suitable bison version was released. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes

Re: [HACKERS] ECPG fix for mixed case cursor names

below doesn't notice the cursor's double declaration and complains using an undeclared cursor: ... Applied. Thanks for spotting and fixing this. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian

[HACKERS] Re: ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname

preproc.y to allow for variable cursor names but in my test case everything seems to work well and $0 gets replaced by the cursor name. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot

Re: [HACKERS] Git migration timeline

having a chance to test it. Anyway, I applied Zoltan's memleak patch to HEAD and 8.4. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber

Re: [HACKERS] Git migration timeline

On Tue, Aug 17, 2010 at 11:50:20AM +0200, Magnus Hagander wrote: What about 9.0? Will come in a few minutes. I didn't have a checked out version of the 9.0 branch handy in my development environment. Regression test is currently running. Michael -- Michael Meskes Michael at Fam-Meskes dot De

[HACKERS] Re: [HACKERS] ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname

. I'd prefer to fix this in 9.0.1. Hope this cleans it up a bit. Michael Kevin Grittner kevin.gritt...@wicourts.gov schrieb: Michael Meskes mich...@fam-meskes.de wrote: I'd consider this a bug. Could you explain why? The assertions that people consider it a bug without explanation of *why

Re: [HACKERS] ECPG FETCH readahead

to add all this even for native ecpg mode. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força

Re: [HACKERS] ECPG FETCH readahead

for that one customer of yours if it only hits them. Now the thing to discuss is how common is this situation. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype

Re: [HACKERS] ECPG FETCH readahead

as you want in one go, something ESQL/C apparently cannot do. This patch is a workaround for that restriction. I still do not really see that this feature gives us an advantage in native mode though. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org

Re: [HACKERS] [PATCH] Move 'long long' check to c.h

hand I didn't want to release with that bug in there. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia

Re: [HACKERS] [PATCH] Move 'long long' check to c.h

defines, but I'd guess there aren't. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça

Re: [HACKERS] [PATCH] Move 'long long' check to c.h

to argue that we shouldn't have one that exists only for ecpg. I think we should fix this (properly) for 9.0. Ok, I don't mind fixing it properly for 9.0. Will do so as soon as I find time. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael

Re: [HACKERS] Two C-interface issues on -Testers

directory so they get attention. I will follow up with the reporters. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes

Re: [HACKERS] Problems with variable cursorname in ecpg

On Wed, Mar 31, 2010 at 01:15:20PM +0200, Boszormenyi Zoltan wrote: I was thinking about something like the attached patch. It passes all the regression tests. Thanks. Applied. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael

Re: [HACKERS] Problems with variable cursorname in ecpg

to allow those? Forbidding these right now would give us more headroomfor future development. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype

Re: [HACKERS] ECPG pointer vs array

, just new types got added. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF

Re: [HACKERS] Problems with variable cursorname in ecpg

works. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian

[HACKERS] Problems with variable cursorname in ecpg

it works fine, but ecpg will still throw an error message, which is not a good situation either. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype

Re: [HACKERS] ECPG, two varchars with same name on same line

. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux

Re: [HACKERS] ecpg compiler warning about char* comparison

On Mon, Mar 08, 2010 at 10:46:03AM +0900, Takahiro Itagaki wrote: There is a complier warning in ecpg/ecpglib/error.c on HEAD: ... Instead, should we use if (strcmp(...) == 0) here? Exactly. Thanks for spotting this, fixed in HEAD. Michael -- Michael Meskes Michael at Fam-Meskes dot De

Re: [HACKERS] ECPG, two varchars with same name on same line

On Fri, Feb 26, 2010 at 10:23:19PM -0500, Bruce Momjian wrote: Was this fixed? No, need to get along to fixing it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304

Re: [HACKERS] NaN/Inf fix for ECPG

On Fri, Feb 26, 2010 at 11:14:01AM -0500, Tom Lane wrote: I think it would be a good idea, just to have all that code using identical #includes. R�mi's problem may be a platform bug rather Sounds reasonable, done. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: [HACKERS] NaN/Inf fix for ECPG

On Fri, Feb 26, 2010 at 12:12:10PM +0100, Boszormenyi Zoltan wrote: Michael, can we try to install the first two patches? If I understood the rest of the thread correctly this is not needed anymore, right? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com

Re: [HACKERS] [GENERAL] libecpg versions and libecpg_compat

? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux

Re: [HACKERS] NaN/Inf fix for ECPG

On Tue, Feb 16, 2010 at 12:21:34PM +0100, Boszormenyi Zoltan wrote: Does FreeBSD/MIPS really return true for isinf(NaN)? Actually it's a netbsd beta version, so maybe there's a bug in their libc. But anyway, the patch doesn't seem to hurt, so I committed it. Michael -- Michael Meskes

Re: [HACKERS] NaN/Inf fix for ECPG

I realized my typo after sending my mail. Sorry if I offended anyone calling NetBSD FreeBSD. :-) I was trying to stress the *beta* status. Maybe someone into NetBSD might be interested in reporting this as a bug. At least it behaves different to all other archs we have. Michael -- Michael

Re: [HACKERS] NaN/Inf fix for ECPG

On Tue, Feb 16, 2010 at 10:28:00PM +0100, Michael Meskes wrote: I was trying to stress the *beta* status. Maybe someone into NetBSD might be interested in reporting this as a bug. At least it behaves different to all other archs we have. Hmm, it seems the patch didn't work. Back

Re: [HACKERS] patch to implement ECPG side tracing / tracking ...

already being sufficient though. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF

Re: [HACKERS] buildfarm breakage

one line defines, so it doesn't look like a major problem adding these. I will try fixing this, but bear with me as I have to use the buildfarm for testing. I don't have a Windows build environment. If someone is willing to run a test on Windows for me, please tell me. Michael -- Michael Meskes

Re: [HACKERS] buildfarm breakage

For the regression test, I am inclined to just do #ifdef WIN32 #define isnan(x) _isnan(x) #define isinf(x) _isinf(x) #endif Well the isinf() macro is different in win32.h. I did make a change and apparently red_bat is now green again. Hopefully that was it. Michael -- Michael Meskes

Re: NaN/Inf fix for ECPG Re: [HACKERS] out-of-scope cursor errors

not have a Windows build system either. So could you please re-diff? The patch also contains cleanups in the outofscope and sqlda regression tests so they do #include pgtypes_numeric.h instead of exec sql include pgtypes_numeric.h; Is there a reason for this? Michael -- Michael Meskes

Re: NaN/Inf fix for ECPG Re: [HACKERS] out-of-scope cursor errors

On Wed, Feb 03, 2010 at 10:59:57AM +0100, Boszormenyi Zoltan wrote: Also, another oversight needs fixing on my part, for which the patch is atttached. The INSERT statement in nan_test.pgc contains platform dependent strings, inf instead of infinity. Committed. Michael -- Michael Meskes

Re: NaN/Inf fix for ECPG Re: [HACKERS] out-of-scope cursor errors

: parameter 2 = -Infinity [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ecpg_execute on line 39: OK: INSERT 0 1 [NO_PID]: sqlca: code: 0, state: 0 == Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael

Re: NaN/Inf fix for ECPG Re: [HACKERS] out-of-scope cursor errors

On Tue, Feb 02, 2010 at 03:34:24PM +0100, Boszormenyi Zoltan wrote: Here's the new patch with the updated regression test. Committed. Thanks a lot. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian

Re: [HACKERS] out-of-scope cursor errors

On Fri, Jan 29, 2010 at 06:32:20AM +0100, Boszormenyi Zoltan wrote: I know. Patches were already posted for that, waiting for Michael to review and apply it. Just came back from another trip. Patch works on my system, so I committed it. Michael -- Michael Meskes Michael at Fam-Meskes dot De

Re: [HACKERS] ECPG patch 4.1, out-of-scope cursor support in native mode

Should I send you a new patch without this regression test or do you delete it before applying the patch? Na, I will just remove it, no need to worry. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes

Re: [HACKERS] ECPG patch 4.1, out-of-scope cursor support in native mode

notice. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU

[HACKERS] ECPGset_var

Zoltan, could you please look into this: http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dugongdt=2010-01-26%2011:05:01 ? Apparently dugong creates the ECPGset_var statements in a different order than the other archs. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: [HACKERS] ECPG patch 4.1, out-of-scope cursor support in native mode

of not spitting out ECPGget_var's? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF

Re: [HACKERS] ECPG patch 4.1, out-of-scope cursor support in native mode

) is a unified one, it would show the problem for native mode as well. That was my feeling too and the reason for these questions. Again, this has nothing to do with the feature you implemented, it was just about this special test. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael

Re: [HACKERS] ECPG patch 4.1, out-of-scope cursor support in native mode

. But what I was wondering about was why this is used as test case. While I see the need to test this part of ecpg I thought this test case was added because it showed a problem without your changes. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael

Re: [HACKERS] Fix auto-prepare #2

has a const, callers assume that they can pass a not-strdup'ed string as the argument. Valid point, I can see no reason for not making this a const char *. So let's try. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De

Re: [HACKERS] ECPG patch 4.1, out-of-scope cursor support in native mode

(int), ... Why does the preproc spit out ECPGset_var's but no ECPGget_var's in this test case? Michael Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo

Re: [HACKERS] ECPG patch 4.1, out-of-scope cursor support in native mode

system. Is it an additional test that just happened to be included here? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes

Re: [HACKERS] ECPG DESCRIBE [OUTPUT] support

On Fri, Jan 15, 2010 at 01:16:18PM +0100, Boszormenyi Zoltan wrote: Please, also add this small change that adds ecpg_raise() calls to ECPGdescribe() to return the proper sqlca error in error paths for: ... Done. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: [HACKERS] patch to implement ECPG side tracing / tracking ...

. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU

Re: [HACKERS] patch to implement ECPG side tracing / tracking ...

-prepared statements even if the statement is not auto prepared? Some statements are not profiled, how did you decide which one to do? There is no test case. Before looking into it in detail I think we should first figure out if this feature really has a benefit. Michael -- Michael Meskes Michael

Re: [HACKERS] ECPG patch causes warning

On Wed, Jan 13, 2010 at 09:22:28AM +0100, Boszormenyi Zoltan wrote: I think it's best to assume a string. ecpg_set_{compat,native}_sqlda() uses the defailt case in that meaning anyway. Okay, applied as you send it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: [HACKERS] ECPG patch causes warning

even earlier as the return value then is stort in a short int because that's what the other sqlda deffinitions use too. Therefore we have to make sure we do not cross the short max. I'm glad at least one compiler caught this. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael

Re: [HACKERS] [COMMITTERS] pgsql: Also update ChangerLog file.

could get all this from the cvs log too. The file has been there for a long time. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes

<    1   2   3   4   5   6   7   >