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

advice is to > drop the Changelog file and be sure you describe changes appropriately > in the commit messages. You definitely get a +1 from me as this file only means additional work that tends to be forgotten. And yes, it does not have any information that the CVS log doesn't hav

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

But I guess we 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:

Re: [HACKERS] unresolved bugs

On Wed, Jan 06, 2010 at 03:36:39PM -0500, Tom Lane wrote: > > BUG #5236: Aparent bug in ecpg > > http://archives.postgresql.org/pgsql-bugs/2009-12/msg00078.php > > Michael needs to look at that one. I'm waiting for a reproducable test case. Michael -- Michael Meskes Mi

Re: [HACKERS] ecpg compile error

On Wed, Jan 06, 2010 at 09:42:06AM +0100, Boszormenyi Zoltan wrote: > Attached. Passes "make check" here on 32-bit and > 64-bit builds under Fedora 9/x86-64. Applied. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at Bo

Re: [HACKERS] ecpg compile error

that I committed Zoltan's patch. 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 Ba

Re: [HACKERS] ECPG SQLDA support

does use int64. However, ecpg uses HAVE_LONG_LONG_INT64 to decide whether it's datatype ECPGt_long_long exists. I changed the patch to use the same define as usual. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Mes

Re: [HACKERS] ECPG SQLDA support

preprocessor I changed this to use the already existing _ECPG_INFORMIX_H define. 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: michaelmesk

Re: [HACKERS] ECPG patch N+1, fix auto-prepare

epare test out of the parser. 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 Bar

Re: [HACKERS] ECPG patch N+1, fix auto-prepare

t; Is it acceptable? Yes sure. I changed some small parts of your patch (see above) and will commit in a few minutes. Just running regression tests. 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|P

Re: [HACKERS] ECPG patch N+1, fix auto-prepare

ething? Besides I don't think it's a good idea to create a local variable overriding a global one with the same 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 Org ICQ: 179

Re: [HACKERS] ecpg.addons

On Thu, Nov 26, 2009 at 11:14:54AM -0500, Tom Lane wrote: > Michael Meskes writes: > > I wrote a hackish little script that checks if all rules in ecpg.addons are > > indeed used to create the precompiler's parser to catch renamed symbol and > > similar changes. Now I

[HACKERS] ecpg.addons

t the ones breaking the regression tests. However, this might also make the buildfarm become red if only a very minor and unimportant change is not syncronized. Any comment? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan d

Re: [HACKERS] ECPG patch 1, dynamic cursorname

ur work. 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:

Re: [HACKERS] [INTERFACES] ecpg & 8.3 -> 8.4 migration

at you saw back then in 7 something, or a bug you still see? > If you're interested in more detail, I have code fixes (they are at work so > I'll send on Monday). Please send them. I'm interested. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Co

Re: [HACKERS] [INTERFACES] ecpg & 8.3 -> 8.4 migration

nd words to > express my dissatisfaction with that. The unreserved_keyword list might I cannot agree more. Sorry about that, it seems this one got forgotten. I wasn't aware of this blunder. Thanks for fixing it Tom. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes

Re: [HACKERS] CommitFest 2009-11 Call for Reviewers

ier for him to review the No, not really. I don't mind reviewing and committing to the core grammar at all. What holds me back is simply my lack of 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 (Deb

Re: [HACKERS] CommitFest 2009-09, two weeks on

chael asked him to do so. Actually these patchsets add different features. I see no reason why they should be done as one patch. However, I haven't had the time to look into the latest ones, but at least that was the situation when I asked Zoltan to split the patch. Michael -- Michael Meskes

Re: [HACKERS] ECPG: store own copy of the prepared statement name

pg_strdup() which does all the error handling needed. I changed this and committed the 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 ICQ: 179140304, AIM/Yahoo/Skype: mich

Re: [HACKERS] Review of "SQLDA support for ECPG"

te the documentation for all changes at once. > I would have the same situation that happened with the code, > the patches with the documentation added would strictly depend > on each other again. Also, Michael Meskes applied the "string" > pseudo-type patch without the docum

Re: [HACKERS] CommitFest 2009-09, two weeks on

d for batch programming. Examples? 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 Go VfL Borussia! Go SF

Re: [HACKERS] CommitFest 2009-09, two weeks on

at that patch" > was an (I thought) polite request, it's really two one-liners. Well, this is true as the patch was buried in the long thread containing all the other ones. And yes, now that you brought it into my memory again, I already committed it. Sorry for missing it. Michael -

Re: [HACKERS] CommitFest 2009-09, two weeks on

commit was one of your patches, obviously I didn't do anything on ecpg since. I'm not sure what you are trying to tell me, you might want to explain the last two sentences. But keep in mind you are *not* the one to decide how I spend my spare time. Michael -- Michael Meskes Michael at

Re: [HACKERS] CommitFest 2009-09, two weeks on

rom the top of my head, so please bear with me if I missed any changes in the patches. 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,

Re: [HACKERS] clang's static checker report.

k/scan-build-2009-09-14-1/report-3LPmKK.html#EndPath it tells me that the value stored to 'counter' is never used. However, the "counter++" is called inside a loop and thus will be read the next time the loop is run. Looks to me like a bug, or did I miss something? Michael -

Re: [HACKERS] Split-up ECPG patches

ns then? 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 Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linu

Re: [HACKERS] Split-up ECPG patches

the check fails. What heppens if the sqlda is incompatible? 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 Go VfL B

Re: [HACKERS] Split-up ECPG patches

ecpg_raise(lineno, ECPG_NOT_FOUND, > ECPG_SQLSTATE_NO_DATA, NULL); \ > + return (false); \ > + } > + Could you please explain why you removed this test for some queries? Is there a bug in there? Michael

Re: [HACKERS] DECLARE doesn't set/reset sqlca after DECLARE cursor

several things in your patch mainly due to chosing a slightly different way to reset the sqlca array and committed that change. Please test. 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|Postgresq

Re: [HACKERS] DECLARE doesn't set/reset sqlca after DECLARE cursor

with just a DECLARE statement and one with a DECLARE statement in a function and post the results please. 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] CommitFest 2009-07: Remaining Patches

On Thu, Aug 13, 2009 at 11:27:54PM -0400, Robert Haas wrote: > (2) ECPG dynamic cursor, SQLDA support. I think we're still waiting > on Michael Meskes to review this one. No. The first part of the patch needs some work and Zoltan is already working on it. Michael -- Michael Meskes

Re: [HACKERS] DECLARE doesn't set/reset sqlca after DECLARE cursor

oc/variable.pgc reflects DECLARE by definition is a declarative command and as such should be able to live outside a function. 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: 17914

Re: [HACKERS] Split-up ECPG patches

On Sat, Aug 08, 2009 at 05:29:06PM -0400, Tom Lane wrote: > around nontrivial expressions. So I'd like to see an actual case made > that there's a strong reason for not requiring FROM/IN in ecpg. I guess there's only one, compatibility. Michael -- Michael Meskes Michael

Re: [HACKERS] Split-up ECPG patches

llows the cursor name as a variable but has neither FORWARD/BACKWARD nor FROM/IN. Zoltan, could you please check whether my docs are right? A quick google search seems to suggest that the same holds for Oracle that apparently allows less options. Michael -- Michael Meskes Michael at Fam-Meske

Re: [HACKERS] Split-up ECPG patches

at I meant was, that other dbms should have the same problem. So they solved it one way or the other. And we could create both solutions just depending on the mode we're in. Informix e.g. doesn't seem to allow a variable to carry the number of records. Heck, I don't even see FORWARD/BACK

Re: [HACKERS] Split-up ECPG patches

atement without from/in is an addition on top of the standard. I'm not sure if any other dbms still allows this construct, so we might we well remove it for 8.5. Or move it to a special compatibility mode. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|C

Re: [HACKERS] Split-up ECPG patches

Some variable handling commands look suspicious to me, a test case might alleviate my concerns. 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: mi

Re: [HACKERS] Split-up ECPG patches

line should attribute copyright to UCB/PGDG. > Michael is free to dictate something else for ECPG of course ... No special rule for ecpg, I absolutely agree. 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] Split-up ECPG patches

see a reason why this should be handled differently. 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 Go VfL

Re: [HACKERS] Split-up ECPG patches

copyright/licensing issue with sqlda? 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 Go VfL Borussia! Go SF 4

Re: [HACKERS] ECPG support for struct in INTO list

e source code you will see this: * This breaks standard and leads to some very dangerous programming. * Since they do, we have to work around and accept their syntax as well. * But we will do so ONLY in Informix mode. Michael -- Michael Meskes Michael at Fam

Re: [HACKERS] Split-up ECPG patches

h and the commit it. Not having read the Informix specs I might have broken something, so please test. 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/Ya

Re: [HACKERS] ECPG support for struct in INTO list

ointed you to one working example. Anyway I attached a modified test28.pgc that should work in compatibility 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,

Re: [HACKERS] ECPG support for struct in INTO list

could be sufficient. 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 Go VfL Borussia! Go SF 49ers! Use Debian G

Re: [HACKERS] status of ECPG patches?

Zoltan provided an updated version which I have to get into again. > When? > > ECPG dynamic cursor, SQLDA support > ECPG support for string pseudo-type v2 As soon as I find the time, but you probably know that the first days after coming back from vacation are kind of crazy. Michael --

Re: [HACKERS] ECPG support for struct in INTO list

; I think this would be a good solution. What do you think? No, this doesn't seem right. There should be no need to unroll a struct. Instead I would think struct support should be added to the get_var/set_var functions. At least that's my guess without really digging into it. Michae

Re: [HACKERS] ECPG dynamic cursor, SQLDA support

; same license as PostgreSQL Oops, didn't notice that this still had the old text, fixed in CVS. > + * (C) 2009 Cybertec GmbH > + * Zoltán Böszörményi > + * Hans-Jürgen Schönig > + */ So am I right to assume that the consensus is to not accept this kind of notice? Mich

Re: [HACKERS] ECPG support for struct in INTO list

es. Just look at test/compat_informix/test_informix.pgc for a real and working example. 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

Re: [HACKERS] ECPG support for struct in INTO list

pposed to do. 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 Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use

Re: [HACKERS] Split-up ECPG patches

On Wed, Jul 15, 2009 at 07:17:17PM +0200, Böszörményi Zoltán wrote: > as asked by Michael Meskes, I have split up our ECPG patchset: Just a couple quick comments. It appears to me (without much testing) that the patches still partly rely on each other. But I cannot see a reason for this.

Re: [HACKERS] ECPG support for struct in INTO list

d fix the bug. Your patch probably/hopefully is not needed. 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

Re: [HACKERS] ECPG support for struct in INTO list

fields in a C struct. Well, this was supposed to work. > Currently ECPG dumps core on this, more exactly aborts on it > in ecpg_type_name(). Could you please send an example where it dumps core? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|

Re: [HACKERS] Odd historical fact about Bison

had reached the limit of older bison versions. So OSX 10.4.11 doesn't work anyway. 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: michae

Re: [HACKERS] ECPG support for string pseudo-type

ot have such a typedef because it wouldn't/shouldn't work there either. Also the new datatype needs some documentation. 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

Re: [HACKERS] ECPG support for string pseudo-type

On Sat, Jul 04, 2009 at 03:39:14PM +0200, Boszormenyi Zoltan wrote: > The attached patch is built upon our previous patch supporting > dynamic cursor and SQLDA. Please don't do this unless the new patch relies on some changes made in the older one. Michael -- Michael Meskes Mic

Re: [HACKERS] ECPG dynamic cursor, SQLDA support

On Wed, Jun 24, 2009 at 11:51:57AM +0200, Boszormenyi Zoltan wrote: > attached is our latest patch extending ECPG: Just as a short explanation, the older versions were sent to me only and I reviewed them. I haven't found time to to review this one yet though. Michael -- Michael Meskes

Re: [HACKERS] Warnings in compile

is at least as save as the old version. Therefore I just commit this small change. 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: michaelmeskes,

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

(Current) = (Rhs)[0]; \ } while (0) I have to admit that those version look strikingly unsimilar to me. There is no reference to Rhs[N] in our macro at all. But then I have no idea whether this is needed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Mes

Re: [HACKERS] Compiler warning cleanup - unitilized const variables, pointer type mismatch

These two should be the same, both coming from bison. Both files are auto-generated, thus it might be bison that has to be fixed to remove this warning. Given that I didn't find any mentioning of preproc in your patch I suppose it just hit the wrong list though. Michael -- Michael Meskes M

Re: [HACKERS] Warnings in compile

.. ] What might be both safe and warning-free > is to code an explicit empty statement, viz macro body as > > if (1) { ... } else ((void) 0) Will try, but probably not now. :-) michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael

Re: [HACKERS] Warnings in compile

.3. As soon as I add the empty braces, the warning is gone. But without really understanding the need for this I certainly don't want to make that change. Maybe Bruce can comment. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot

Re: [HACKERS] Warnings in compile

On Mon, May 25, 2009 at 10:19:40AM -0400, Tom Lane wrote: > Michael Meskes writes: > > - some combination of signed and unsigned: ~ 600 > > Are we really sure that *all* compilers out there do handle this > > correctly? > > The behavior is spelled out in the C spec

[HACKERS] Warnings in compile

that are called as foo; I see the need for the macro to expand as block, but what use hase the empty else? I assume that the only warning outside these classes is a false positive. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at

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

ease has been done. Comments anyone? 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: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use D

Re: [HACKERS] Which installation parts are backward compatible?

On Mon, Feb 16, 2009 at 12:39:32PM +0200, Peter Eisentraut wrote: > On Monday 16 February 2009 12:06:55 Michael Meskes wrote: > > On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote: > > > Will a program built with ecpg 8.4 run against a 7.4 server work the >

Re: [HACKERS] Which installation parts are backward compatible?

o, if the program's SQL is 8.4 specific it won't work. 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: michaelmeskes, Jabber: mes...@jabber.org Go

Re: [HACKERS] Which installation parts are backward compatible?

mar accepted will surely be different. But running a new application with a new ecpglib against an old server works as long as libpq 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 O

Re: [HACKERS] Compiler warning in ecpglib/execute.c

issing error checks in that library that might explain the segfaults, but I still don't see why the the test is failing. 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: 179

Re: [HACKERS] Compiler warning in ecpglib/execute.c

On Mon, Feb 02, 2009 at 02:56:18PM -0500, Tom Lane wrote: > CVS HEAD is producing > ... Thanks for the note, I missed this copy&paste error of mine. Fixed in HEAD. This should alos make the buildfarm green again. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Mesk

Re: [HACKERS] ecpg regression test failures caused by window functions patch

was a test that expected the blank and thus looked into $1[1] instead of $1[0]. :-) I hope I found all of these. 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

Re: [HACKERS] ecpg regression test failures caused by window functions patch

(res_str, " "); > + if (strlen(str1) != 0 && strlen(str2) != 0) > + strcat(res_str, " "); > strcat(res_str, str2); > free(str1); > free(str2); > return(res_str); > } Hey, good idea, will add this too

Re: [HACKERS] Looking for someone with MinGW

s it doesn't here. Could you please check this by checking out the changes, re-running "make checktcp" and checking whether the regression.diffs file changes? Thanks Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFa

Re: [HACKERS] Looking for someone with MinGW

s implemented it was taken out of "make check" because it requires a tcp connection, so you have to run "make checktcp" instead. But if noone runs this, we could drop it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at Bo

Re: [HACKERS] Looking for someone with MinGW

On Sun, Dec 14, 2008 at 11:36:21AM -0500, Andrew Dunstan wrote: > See below > ... Thanks. The backtrace is kind of strange, but I might have found it. Could you please update from CVS and re-run? Thanks again. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes d

Re: [HACKERS] Looking for someone with MinGW

end me a backtrace? I guess this has to be debugged so we find out what's going wrong. 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: michaelmes

Re: [HACKERS] WIP: default values for function parameters

re's the lexer rule: :{identifier}((("->"|\.){identifier})|(\[{array}\]))* No space possible between ":" and {identifier}. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debi

[HACKERS] Looking for someone with MinGW

inGW which is outdated, so don't be surprised if the regression tests fail. Alternatively you could check in the file as .../ecpg/test/expected/connect-test1-minGW32.stderr. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at Bor

Re: [HACKERS] Re: Updated interval patches - ECPG [was, intervalstyle....]

On Wed, Nov 26, 2008 at 09:31:48AM -0500, Tom Lane wrote: > Michael, since that's ecpg code, please take charge of committing it > if you want it. Okay, done. I wasn't sure whether this was related to a backend patch that was still under review. Michael -- Michael Meskes Micha

Re: [HACKERS] Re: Updated interval patches - ECPG [was, intervalstyle....]

On Thu, Nov 20, 2008 at 05:07:40PM -0800, Ron Mayer wrote: > Got it. > Patch attached. Looks reasonable to 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 Org ICQ: 17914030

[HACKERS] Re: [COMMITTERS] pgsql: Enable script to generate preproc.y in build process.

'm correctly identifying > the corresponding code in 8.3, it has a semicolon where expected. No, not that old. These rules were introduced at some point after 8.3 was released, so no biggy here. This just meant that we went weeks without any system complaining. Michael -- Michael Meskes Micha

Re: [HACKERS] gram.y => preproc.y

a good idea to list preproc.c's antecedent as > $(srcdir)/preproc.y not just preproc.y. Also, you'll need to add > preproc.y to .cvsignore. Added. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meske

Re: [HACKERS] gram.y => preproc.y

> the script uses it at all, or does it? The new version does. I need to tell the script where to find the other files in a VPATH build system. 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|Post

Re: [HACKERS] gram.y => preproc.y

dy committed the new files, so the patch is way smaller. However, the new files are not used without the attached changes to the build system. Does anyone see a problem with these changes? Or else I will commit. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|

Re: [HACKERS] gram.y => preproc.y

On Thu, Nov 13, 2008 at 03:57:49PM -0500, Tom Lane wrote: > Michael Meskes <[EMAIL PROTECTED]> writes: > > That's what I did first, but Magnus had a good reasoning to not keep > > preproc.y > > if we keep preproc.c in our tarball. And I agreed that there doesn&#x

Re: [HACKERS] gram.y => preproc.y

n CVS. That's what I did first, but Magnus had a good reasoning to not keep preproc.y if we keep preproc.c in our tarball. And I agreed that there doesn't seem to be an advantage. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Ja

[HACKERS] gram.y => preproc.y

Hi, since my last email seems to have disappeared, here we go again. Here's my current patch that includes the changes to the build system. Thanks to Magnus for the Windows part. Comments anyone? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Ne

Re: [HACKERS] Re: Updated interval patches - ECPG [was, intervalstyle....]

pg/pgtypeslib/dt.h. The numbers should match IMO. Also one files seems to be missing, there are no changes to test/expected/pgtypeslib-dt_test.c in the patch, but when changing dt_test.pgc this file should be changed too. Could you add this to your work too? Michael -- Michael Meskes Michael at Fa

Re: [HACKERS] [I|S]CONST/[I|S]const in gram.y

mixed-case spelling looks like a non-terminal and at some point people will spend time looking to the rules defining these non-terminals. 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] gram.y=>preproc.y

gt; preproc.y and compare the result to pgsql/src/interfaces/ecpg/preproc/preproc.y. Both files should be identical. 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] gram.y=>preproc.y

ier into each file that > will be added to CVS? Definitely. 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: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL

[HACKERS] gram.y=>preproc.y

perl hacker can beautify the script quite a bit. Anyway, it does work, regression tests run through (need to update expected results though). So guys, now's the time to test before it makes it into the archive. :-) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meske

Re: [HACKERS] [I|S]CONST/[I|S]const in gram.y

So yes, I'd remove Iconst/Sconst. 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: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers

[HACKERS] [I|S]CONST/[I|S]const in gram.y

e all rules use the same symbol which will make gram.y be consequent in its symbol usage and simplify my work to generate the ecpg parser out of an unchanged gram.y at the same time. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFa

Re: [HACKERS] gram.y => preproc.y

ert something before that second rule, it won't work anymore. > FWIW, I'm also pretty firmly convinced that awk was the wrong choice for > implementing this script... Well, I work with what I have. What language would you prefer? And btw what makes you so convinced? Michael -- Michae

[HACKERS] gram.y => preproc.y

ference any more. To test you need an up-to-date HEAD because ecpglib didn't like an additional blank. Comments/improvements/bug reports welcome. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debi

[HACKERS] Email/lists setup

o contact? 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: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use Po

Re: [HACKERS] automatic parser generation for ecpg

y better for the > purpose. Well I think it's at least readable. Problem with your approach is that both Mike and I feel more comfortable with awk at the moment. If a2p produces a working perl script, that doesn't seem to be a problem IMO as we could maintain the awk script but deliver

Re: [HACKERS] binary representation of datatypes

mestamp 'official' format, i mean > timestamp expressed as number of microseconds since > 2000-01-01. But of course, it only deserves this name 'official' if it is > guaranteed to stay the same across postgresql versions and > platforms You shouldn't rely on this. Ag

Re: [HACKERS] automatic parser generation for ecpg

se it is new. Is this understandable? :-) 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: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF

Re: [HACKERS] binary representation of datatypes

7: RESULT: 1966-01-17 offset: -1; array: yes [NO_PID]: sqlca: code: 0, state: 0 [NO_PID]: ecpg_get_data on line 37: RESULT: 2000-07-12 17:34:29.140787 offset: -1; array: yes [NO_PID]: sqlca: code: 0, state: 0 ... What do I miss here? Michael -- Michael Meskes Michael at Fam-Meskes dot De, M

Re: [HACKERS] [INTERFACES] ecpg 'set' failure using host vars

ema > [22245]: ecpg_check_PQresult line 13256: Error: ERROR: syntax error at or > near "$1" > LINE 1: set search_path to $1 Without checking the sources it seems as if PQexecParams is not able to handle a parameter in a set command. Can anyone confirm this? Michael -- Michael Mesk

<    1   2   3   4   5   6   7   >