Re: Fix some memory leaks in ecpg.addons

tools like ecpg to not worry about memory. After all it gets freed when the program ends. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG Semantic Analysis

hom can I discuss it? Feel free to send it to me. Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG Semantic Analysis

Hi, > I have a modified version of ECPG, to which I gave the ability to > do semantic analysis of SQL statements. Where i can share it or with > whom can I discuss it? Feel free to send it my way. Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (D

Re: SQL/JSON functions vs. ECPG vs. STRING as a reserved word

lLabelCommon uses and adds a hard-wired special case for > STRING to handle the var_type usage. I'm fine with this approach. Thanks Tom. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

st this particular feature and remove the warning? After all this is not the way the statement should be used, hence the warning. Or should be keep it in and redirect the warning? In that case, we would also lose other warnings that are not planned, though. Any comments? Michael -- Michael Meskes Micha

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

en I accept that. After all, the reason we > want you to deal with this is not only that you made the original > commit > but because you're the expert in this area. I will commit the patch(es). Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

QL DEALLOCATE PREPARE stmt_2; > > And DEALLOCATE is far from being new. I'm not sure I understand. Any usage of DECLARE STATEMENT makes the file need the current version of ecpg anyway. On the other hand DEALLOCATE did not change its behavior if no DECLARE STATEMENT was issued, or what did I

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

decision whether we commit Kuroda-san's patches? They are fine by me. Another pair of eyes would be nice, though. maybe you could have another look, Horiguchi-san? Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

meone, > unless someone asks. Completely agreed, my point was that documenting the process to some extend would be helpful. For obvious reasons I'm the wrong person to do that, though. :) Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

> I do think all committers need to understand the role of the RMT so > they > can respond appropriately.  Do we need to communicate this better? Being the one who assumed a different procedure, yes please. :) Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at M

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

... DESCRIBE ...; already anyway. Again, not very meaningful but why should we accept a connection one way but not the other? Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org signature.asc Description: This is a digitally signed message part

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

ichael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

on an ecpg > issue.  Not sure if that was before or after Peter's email. I think that was before, at that point I still thought it was nothing time sensitive. And unfortunately it didn't register that RMT was involved at all. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

al issue that kind of started this whole mess. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

idence they > have > in this getting resolved in a timely manner. Again agreed, please keep in mind, though, that I didn't notice I was being chased until Peter's first email. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

oing that. And other databases are not really strict about this either. > I would be interested in hearing your view, and that of others, on > whether this is really a bug at all. I think the question is more which version of the patch we commit as it does increase the functionality of ecpg.

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

the first place? I just don't understand this at all. I'm getting very tired of you accusing me of things I neither said nor did. Please stop doing that or show me the email where I said the patch was "inconsequential"? As for writing a brief email, please read all the other emails in t

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

avoided at all costs. Why > should people that don't know anything about ecpg make decisions > about > ecpg? In general they should not. Well, you did lay out what the decision would be and I fully agreed with it. So again, what was there to do? Had you asked me if I agreed, I would told you

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

That's why a short glance at the patch didn't suffice to answer this. I didn't see any issues with the patch so far. Please send it to me once its finished (or is it already?) and I'll give it a run, too. Hopefully I caught up on all emails and didn't miss parts of the thread. Thanks, Michael -- Michael

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

dline which I understand and accept. But then I never said a word against it, so the question remains, why accusing me of something I never did? > Again, the scope of what you're complaining about was (and still is) > unclear to me. I'm sorry, but I have no idea how to explain it more clearly.

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

On Sat, 2021-08-07 at 15:31 -0700, Peter Geoghegan wrote: > On Sat, Aug 7, 2021 at 12:43 PM Michael Meskes > wrote: > > Again, I didn't know the RMT was expecting anything from me. Yes, I > > knew I needed to spend some time on a technical issues, but that's > > exact

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

say I expect you to wait? How could I even do that given that I didn't even know you were waiting for a status update from me? Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

Hi Peter, > The RMT continues to be concerned about the lack of progress on this > open item, especially the lack of communication from Michael Meskes, > the committer of the original patch (commit ad8305a). We are prepared > to exercise our authority to resolve open items direct

Re: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

All, > between DECLARE and the past queries qualify as an open item.  I am > adding Michael Meskes in CC.  I got to wonder how much of a > compatibility break it would be for DEALLOCATE and DESCRIBE to handle > EXEC SQL AT in a way more consistent than DECLARE, even if these a

Re: [PATCH] ecpg: fix progname memory leak

here. While I agree that it makes debugging of memory handling in ecpg more difficult, I don't see much of a point in it. Michael -- Michael Meskes Michael at Fam-Meskes dot De Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: ECPG: proposal for new DECLARE STATEMENT

> This patch has now been silent for quite a while, unless someone is > interested > enough to bring it forward it seems about time to close it. I am interested but still short on time. I will definitely look into it as soon as I find some spare minutes. Michael -- Michael Meskes Micha

Re: MinGW compiler warnings in ecpg tests

se, or in other words, if you ask me go ahead with your patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: A problem presentaion about ECPG, DECLARE STATEMENT

viously way too late for 12. Sorry for the noise. In this case I'd like to details about what is wrong with the implementation. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot

Re: A problem presentaion about ECPG, DECLARE STATEMENT

ble where possible. > In order to modify bugs, I think many designs, implementations, > and specifications should be changed. I hope the authors of said patch speak up and explain why they implemented it as is. > Is it acceptable for PG12? In general absolutely. Michael -- Michael Mes

Re: [PATCH] memory leak in ecpglib

Hi, > Memory leaks occur when the ecpg_update_declare_statement() is called > the second time. > ... I'm going to commit this patch HEAD, this way we can see if it works as advertised. It does not hurt if it gets removed by a rewrite. Thanks for finding the issue, Michael -- Micha

Re: Bug: ECPG: Cannot use CREATE AS EXECUTE statemnt

t spends more time for implementing. Do you have any advice? > ... Unfortunately no, I have no advice. Originally all statements needed this treatment. :) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber

Re: coverage additions

nt this test to be run by default, and thus I > > should > > add "make -C src/interfaces/ecpg/test checktcp" to > > coverage.pg.org's > > shell script? > > I believe it's intentionally not run by default because it opens up > an externally-accessible serv

Re: SQL statement PREPARE does not work in ECPG

igured worse case we can revert the patch if people object. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux

Re: SQL statement PREPARE does not work in ECPG

> None here. You might want to get it in in the next 12 hours or so > so you don't have to rebase over a pgindent run. Thanks for the heads-up Tom, pushed. And thanks to Matsumura-san for the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|N

Re: SQL statement PREPARE does not work in ECPG

ing environment, a part of character of > message is cut off. > > It may be very difficult to fix. I pretend I didn't see it for a > while. > ... Hmm, any suggestion? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgre

Re: SQL statement PREPARE does not work in ECPG

> allocated > by both PREPARE FROM and PREPARE AS under the following > constraints: > - It must not include a using-clause. > - The statement name must follow to the specification of PREPARE > AS. This look very reasonable to me. I'm completely fine with this restriction being place

Re: fix memory overflow in ecpg preproc module

Hi, > I have found a potential memory overflow in ecpg preproc module. > ... Thanks for finding and fixing, committed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot mesk

Re: SQL statement PREPARE does not work in ECPG

merge. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: SQL statement PREPARE does not work in ECPG

top of > > my head. Need to check when I'm online again. > > I will also consider it. Thank you. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL

Re: SQL statement PREPARE does not work in ECPG

oaches, we will run into issues later. There was a reason why we added PQprepare, but I do not remember it from the top of my head. Need to check when I'm online again. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresq

Re: ECPG regression with DECLARE STATEMENT support

> I attached a simple bug-fixing patch. I'm not happy with the situation, but don't see a better solution either. Therefore I committed the change to get rid of the regression. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Mes

Re: ECPG regression with DECLARE STATEMENT support

throwing an error continue > executing statement "CLOSE cur_name" with ecpg_do(). The problem as I see it is that the cursor is known to the backend but not the library. Takaheshi-san, Hayato-san, any idea how to improve the situation to not error out on statements that used to work? M

Re: SQL statement PREPARE does not work in ECPG

to be conflicting with bd7c95f0c1a38becffceb3ea7234d57167f6d4bf. If we want to keep this commit in for the release, I think we need to get these things fixed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabbe

Re: SQL statement PREPARE does not work in ECPG

This cannot be done with an addon. Please see the attached for a way to do this, untested though. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! S

Re: SQL statement PREPARE does not work in ECPG

Hi Matsumura-san, > I will read README.parser, ecpg.addons, and *.pl to understand. Feel free to ask, when anything comes up. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot mes

Re: SQL statement PREPARE does not work in ECPG

unction in ecpglib. > Is it good? I'd say so. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: [Bug Fix] ECPG: could not use set xxx to default statement

grammar is and that the ecpg tools only parse that one file. Why putting effort into writing it down too? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: SQL statement PREPARE does not work in ECPG

XECUTE test_prep (:i) INTO :ID;".) Ok, thanks. That means the parser has to handle the list of execute arguments differently, which in hindsight is pretty obvious. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org

Re: SQL statement PREPARE does not work in ECPG

lem is that constants in this subtree are move to the output literally instead treated as parameters. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Fo

Re: SQL statement PREPARE does not work in ECPG

;EXEC SQL > EXECUTE test_prep (2);" Correct. As for the PREPARE statement itself, could you try the attached small patch please. This seems to create the correct ECPGPrepare call, but I have not yet tested it for many use cases. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De,

Re: SQL statement PREPARE does not work in ECPG

Matsumura-san, > Maybe, there is no work-around. Did you analyze the bug? Do you know where it comes from? > For supporting it, there are two steps. Could you please start with explaining where you see the problem? I'm actually not sure what you are trying to do here. Michael -- M

Re: SQL statement PREPARE does not work in ECPG

. And yes, it does look like a bug to me, or better like changes in the backend that were not synced to ecpg. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! F

Re: [Bug Fix] ECPG: could not use set xxx to default statement

I think your patch does not notice the end of the rule. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: [Bug Fix] ECPG: could not use set xxx to default statement

n I expected. Thanks. My first test show two "missing" semicolons in gram.y. :) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers

Re: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

Hi Higuchi-san, > I updated and attached the patch. As I show in previous post, this > version is that "IF NOT EXISTS" keyword and variable for "WITH NO > DATA" are added to ecpg.trailer. Thank you, committed. Michael -- Michael Meskes Michael at Fam-Meskes dot

Re: [PROPOSAL]a new data type 'bytea' for ECPG

Matsumura-san, > I attach a new patch. > ... Thank you so much. This looks very good. Committed to HEAD. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot o

Re: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

ERROR, ET_ERROR, "CREATE > TABLE AS cannot specify INTO"); > + > + $$ = cat_str(7, mm_strdup("create"), $2, > mm_strdup("table if not exists"), $7, mm_strdup("as"), $10, $11); > } > ; > >

Re: [Bug Fix] ECPG: could not use some CREATE TABLE AS syntax

change of this rule has been made to make sure this syntax is not accepted. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: [PROPOSAL]a new data type 'bytea' for ECPG

ttr(). I don't think this will help much, don't bother. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: [PROPOSAL]a new data type 'bytea' for ECPG

) Isn't that a better way then? This looks more smoothly to me. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: [PROPOSAL]a new data type 'bytea' for ECPG

ot see the obvious. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: [PROPOSAL]a new data type 'bytea' for ECPG

t_desc() to not use ecpg_store_input() in case of an bytea. This looks odd to me. Can you please explain that to me? Thanks Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot o

Re: [PROPOSAL]a new data type 'bytea' for ECPG

by the preprocessor and replaced by a struct definition anyway. Feel free to remove. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça!

Re: Thread-unsafe coding in ecpg

> I like having a hard limit on the number of loop iterations; > that should ensure that the test terminates no matter how confused > ecpglib is. I get your point and thus will only clean up the tests a little bit. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at M

Re: Thread-unsafe coding in ecpg

ices, but wouldn't it be a better > idea > to break out of the loop on seeing an error? I wonder if it would be better to make the test cases use the proper whenever command instead. That would give us a slightly better functionality testing I'd say. Michael -- Michael Meskes Michael at Fa

Re: Thread-unsafe coding in ecpg

but I didn't see any obvious reason to think so, > so I changed it too. Thanks Tom. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49e

Re: Thread-unsafe coding in ecpg

I don't see > anything so wrong with just documenting the hazard. The situation Actually I meant using setlocale() and documenting that it must not be used with threads, or document it must not be used with locales? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Mesk

Re: Thread-unsafe coding in ecpg

il when they do. The question is, what do we do on those platforms? Use setlocale() or fallback to (a) and document that ecpg has to run in a C locale? We could also rewrite the parsing of numbers to not be locale dependent. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes

Re: Thread-unsafe coding in ecpg

that code and document that you'd better run ecpg > in LC_NUMERIC locale, but it'd be nice if we could do better. How about attached patch? According to my manpages it should only affect the calling threat. I only tested it on my own system so far. Could you please have a look and/or test

Re: [PROPOSAL]a new data type 'bytea' for ECPG

. I'm at a loss here. I don't understand what you are trying to say. An incompatible change is ok if we change the version number of the library accordingly. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: [PROPOSAL]a new data type 'bytea' for ECPG

sqlda will encounter their unknown type(=ECPG.bytea) in > sqlvar_struct.sqltype. You mean if they are not recompiled? If so, yes, how else could that be handled? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber

Re: [PROPOSAL]a new data type 'bytea' for ECPG

ave in our test suite. I'm afraid this will come back to haunt us. > > The patch does not support ECPG.bytea in sqltype of "struct > > sqlvar_struct" > > because of compatibility. Sorry I do not really understand what you mean. Could you please explain? Michael -- Micha

Re: [PROPOSAL]a new data type 'bytea' for ECPG

dard? I don't really see where the usability drawback is. In general I would prefer being as close to the standard as reasonably possible. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmp

Re: Intermittent ECPG test failures on Windows buildfarm machines

a Windows system who could bisect the tree and find which commit is the culprit? Or did we have any changes to the buildfarm scripts that may be causing this? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jab

Re: ECPG oracle mode test program patch

> The attached patch corrects the cursor name. Fixed, thanks for the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers!

Re: Fix error in ECPG while connection handling

ixing. I will push the patch as soon as I'm online again. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: [HACKERS] datetime.h defines like PM conflict with external libraries

it compiles cleanly I'm fine either way. I'm assuming you're talking about including the files for compiling ecpg, not as externally visible header files, right? michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jab

Re: [PATCH] ECPG bug fix in preproc when indicator struct is shorter than record struct

t resolution will do the trick. But thanks for the heads-up. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: [PATCH] ECPG bug fix in preproc when indicator struct is shorter than record struct

ough. :) > If accepted, this bug fix can be back ported to earlier versions of > ecpg as well. As usual this will be done after a couple of days, if no problems appear. I'm pretty sure there won't but sticking to my workflow here. Michael -- Michael Meskes Michael at Fam-Meskes dot De