Re: [HACKERS] Try to fix endless loop in ecpg with informix mode
> Although this error message is not wrong, I think it should be better > to > give error message as "invalid input syntax for type int" for "7.a". > This could be done by delete "return false;" after "while(...)", let > the following if to decide which to return. Ah, now I understand. Sorry, I completely misunderstood your prior email. Yes, you're right, I will change the code accordingly. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Try to fix endless loop in ecpg with informix mode
> I am afraid the changes may separate "7.a" to "7" and "a", then error > out > with "invalid input syntax for type int" for "a". Which is correct, is it not? > How about changes as below? (use following the if to decide true or > false) > ... >return false; > +} while (isdigit(**scan_length)); Yes, this is certainly correct and better than what I committed. What was I thinking yesterday? I think the same function is used for identifying garbage in floats which might ask for different logic. Let me check. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Try to fix endless loop in ecpg with informix mode
> Any comments? Sorry, I've been working through the backlog of three weeks of traveling. > > I tried some tests with ecpg informix mode. > > When trying to store float data into a integer var, I got endless > > loop. > > > > The reason is: > > In informix mode, ecpg can accept > > string form of float number when processing query result. > > During checking the string form of float number, it seems > > that ecpg forgot to skip characters after '.'. > > Then outer loop will never stop because it hopes to see '\0'. > > > > The first patch will reproduce the problem in ecpg's regress test. > > The second patch tries to fix it in simple way. Thanks for spotting and fixing. I changed your patch slightly and made it check if the rest of the data is indeed digits, or else it would accept something like "7.hello" as "7". 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 meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [bug fix] ECPG: fails to recognize embedded parameters
> The cause is that next_insert() in ecpglib unconditionally skips the > next character after the backslash. > > Could you review and commit the attached patch? I also attached the > test program for convenience. Thanks for spotting and fixing. I just committed your patch to master and backported to 9.4, 9.5, 9.6 and 10. It doesn't apply cleanly to 9.3. But then it might not be important enough to investigate and backported to this old a version. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] datetime.h defines like PM conflict with external libraries
> Isn't pgtypeslib/*.h exposed to ecpg-using applications? No, the public interface is is include/*.h, pgtypeslib/*.h is only internal. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] datetime.h defines like PM conflict with external libraries
> Maybe it'd be good idea to unify some of that stuff so that ecpg can > use > it, too? Having a second copy of the same stuff in > src/interfaces/ecpg/pgtypeslib/dt.h is pretty terrible. Even if not, > let's make sure they don't diverge. Please let's unify whatever we can. The fewer manual sync we need, the better. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'
> Oh. If there's actually a standard somewhere that says it's not > null-terminated, then code that is expecting it to be so is just > wrong. No need to change anything in ecpg, IMO. As I said I haven't checked if this detail is actually in there, but I guess it was because there is a reason why we, and other databases, define it that way. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'
> > Why do you think there should be one? My memory might be wrong but > > I > > don't think it's supposed to be a null terminated string. > > That field is defined as char[5] in struct sqlca_t, so the intent is > clearly that it not be null terminated. However, it looks to me like > there'd be at least one alignment-padding byte after it, and that > byte > is likely to be 0 in a lot of situations (particularly for statically > allocated sqlca_t's). So a lot of the time, you could get away with > using strcmp() or other functions that expect null termination. With "supposed" I was referring to the standard that defines SQLCA. > I'm thinking therefore that there's probably code out there that > tries > to do strcmp(sqlca->sqlstate, "22000") or suchlike, and it works > often > enough that the authors haven't identified their bug. The question > is > do we want to try to make that be valid code. > > Changing the field declaration to char[5+1] would be easy enough, but > I have no idea how many places in ecpglib would need to change to > make > sure that the last byte gets set to 0. I doubt it'll be a lot. However, it would make us differ, albeit very slightly, from what others do. I haven't come up with a practical problem coming from that difference 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! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'
> When we reviewed the ecpg code,we found the array seem not have the
> end
> character('\0') after using the strncpy function.
True.
> In the function ECPGnoticeReceiver, we use the stncpy function copy
> the
> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as
> the size
> of 5, and the copy size is sizeof(sqlca->sqlstate). However, from the
> previous strcmp function, the sqlstate size may be 5,such as
> ECPG_SQLSTATE_INVALID_CURSOR_NAME. So there may be lack of the end
> character
> for sqlca->sqlstate.
Why do you think there should be one? My memory might be wrong but I
don't think it's supposed to be a null terminated string.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Build failure on thrips
> woodlouse does not do ecpg-check, and Tom is right anyway. I need to > get a large sign nailed to my forehead that says "Postgres is C, and > declarations must come first." I didn't notice either. I guess /me is getting rusty, sigh. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Build failure on thrips
> Unless someone has a better idea, I'd suggest working around > that like so: > > #ifdef WIN32 > #ifdef _MSC_VER/* requires MSVC */ > _configthreadlocale(_ENABLE_PER_THREAD_LOCALE); > #endif > #endif Let's try, committed, thanks again 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 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Build failure on thrips
> It's not just thrips. Of the Windows machines that have reported in > since > that commit, only currawong and baiji passed. Although lorikeet, > woodlouse, bowerbird, and brolga are showing green, this proves > nothing > because they're all configured to skip the ecpg check (... I wonder > why). I would assume it works on woodlouse as the patch has been submitted by woodlouse's owner. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Build failure on thrips
The bug fix I committed for fixing setlocale in ECPG test cases on Windows seems to work nicely on all buildfarm animals except thrips. Could anyone with access to a similar systems please check what's going on or send the precompiled file that creates the compilation errors? 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Not listed as committer
> Ha, that's interesting. > > Should be fixed now, please try again. Works, thanks Magnus. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action
> Given that it's Friday evening in Europe, I'm betting Michael is gone > for the day. In the interests of getting the buildfarm back to > green, > I'll see if I can fix this. Correct, 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 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Not listed as committer
All, I just committed a patch that is listed in the CF and had to put somebody (I chose you Bruce :)) in as a committer because I was not listed. Do I have to register somewhere? 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action
> The v3 patch looks good to me. I've changed this patch status to Ready > for Committer. Thank you all, 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 meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] assorted code cleanup
> And there are many "(0)" "S_ANYTHING" in src/interfaces/ecpg/test/ and > src/interfaces/ecpg/preproc/. I might have missed something here, but where/why is S_ANYTHING a problem? 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Rust bindings to pgtypes lib
> Indeed. I'm quite strongly against exposing / using pgtypeslib in more > places. If anything it should be phased out. Because that code is Feel free to come up with a replacement. :) > definitely not always kept up2date, and it's a lot of work to do so. If > anything the code should be rewritten to *not* require so much > duplication, then we could talk. Agreed. However, it could be argued that the code is not duplication (anymore) but a separate implementation of these datatypes. >> I'm not aware of any other language binding for pgtypeslib. > > Some people use http://libpqtypes.esilo.com/ Never before saw this. It does not seem to have more in common than the name, 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Rust bindings to pgtypes lib
> But is this possible, or feasible? I see that the makefile refers to Possible yes, but in general I'm not a big fan of duplicating code. I spend too much time to keep those copies in sync. > Makefile.global, and also includes stuff from ecpg, aat least. I don't want > to Yes, but these should be minor. Makefile.global is mostly included for some rules and other than some includes I don't know what else is taken from ecpg. However, there are a couple small files that are taken from teh backend source tree, like pgstrcasecmp.c > How much of the source tree would I have to carve out? > Or from another perspective; how do other language (if any) solve this? I'm not aware of any other language binding for pgtypeslib. 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action
Hi, > To develop the ECPG application more efficiently and improve > portability, > I would like to suggest one minor improvement "WHENEVER condition DO > CONTINUE" support in ECPG. > Oracle Pro*C supports WHENEVER statement with DO CONTINUE action.[1] > > EXEC SQL WHENEVER SQLERROR CONTINUE; > is not same as > EXEC SQL WHENEVER SQLERROR DO CONTINUE; > > The CONTINUE action instructs the client application to proceed to > the next statement whereas DO CONTINUE action instructs the client > application to emit a C continue statement and the flow of control > return to the beginning of the enclosing loop. This did actual escape me. Thanks for bringing it to our attention and fixing this missing functionality. > I have tried to implement it. Please check the attached patch. > Please give me feedback. > ... Could you please add a "DO CONTINUE" case to one of the test cases? Or add a new one? We would need a test case IMO. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is ECPG's SET CONNECTION really not thread-aware?
On Wed, Jun 07, 2017 at 03:45:23AM +, Tsunakawa, Takayuki wrote: > Could you also apply it to past versions if you don't mind? The oldest > supported version 9.2 is already thread-aware. Done. My standard workflow is to wait a couple days to see if everything works nicely before backporting. Obviously this doesn't make any sense for a doc patch, sigh. 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Is ECPG's SET CONNECTION really not thread-aware?
Dear Tsunakawa-san, sorry for the late reply, I've been traveling all of last week and only just came back. >> What does this mean by "not thread-aware?" Does SET CONNECTION in one >> thread change the current connection in another thread? >> It doesn't look so, because the connection management and SQL execution >> in ECPG uses thread-specific data (TSD) to get and set the current >> connection, >> like this: I'm pretty sure it is indeed thread-aware, although I didn't provide the code for this feature myself. > So the doc seems to need fix. The patch is attached. Thanks, applied. 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG: pg_type.h file is not synced
> Bruce Momjian <br...@momjian.us> writes: > > > > But I think the "ecpg/ecpglib/pg_type.h" file is currently not > > > > synced > > > > with the above file. > > Should we add some Makefile magic to make sure they stay in sync? > > Not so much that as teach genbki.pl to generate this file too. > I think that might be a good idea, but personally I'd leave it until > after the genbki rewrite we keep talking about. This isn't important > enough to make that rewrite have an even higher hurdle to clear. > > regards, tom lane Agreed. We will only run into problems with ecpg if some of the existing oids change. Newly added ones will not be referenced unless ecpg receives changes, 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG: pg_type.h file is not synced
Hi, > I am looking at ECPG source code. In the "ecpg/ecpglib/pg_type.h" file I > have seen following comment: > > ** keep this in sync with src/include/catalog/pg_type.h* > > But I think the "ecpg/ecpglib/pg_type.h" file is currently not synced > with the above file. > > I have added the remaining types in the attached patch. > > I would like to know whether we can add remaining types in the > "ecpg/ecpglib/pg_type.h" file or not? It's not too big a deal as neither of the new OIDs is used in ecpg, but still, the file should be up to date. Thanks for the patch, 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 meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Host variables corresponding bytea type in ecpg
> > > I attach modified patch. > > Thank you, committed. > > I don't see a git push for this? Oops, should be there now. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Host variables corresponding bytea type in ecpg
> I attach modified patch. Thank you, 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 meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Two phase commit in ECPG
> Yes. I added two-phase commit test to "make check" test schedule > while > adding new two type of test. Thank you, 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 meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Two phase commit in ECPG
> Thank you for pointing out. > Yeah, I agree that the twophase regression test should not be > performed by default as long as the default value of > max_prepared_transactions is 0. Similar to this, the isolation check > regression test does same thing. Attached patch removes sql/twophase > from schedule file and add new type of regression test. Would it be possible to include it in "make check"? Any check that needs manual interaction will not be executed nearly is often as the others and become much less useful imo. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Two phase commit in ECPG
> Previous 002 patch lacked to add describing PREPARE TRANSACTION. > Attached updated 002 patch. I just committed both patches and a backport of the bug fix itself. Thanks again for finding and fixing. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Two phase commit in ECPG
Dear Sawada-san, > This cause is that the "begin transaction" is issued automatically > before executing COMMIT PREPARED if we're not in auto commit. The > Commit 816b008eaf1a1ff1069f3bafff363a9a8bf04a21 fixed bug of > incorrect > status calculation but at the same time it became the cause of this > behavior. > Is this a bug? I'd say so, yes. As soon as I find time I'll get to it including back porting your patch. Thank you very much for spotting and fixing. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Keep ECPG comment for log_min_duration_statement
> Michael Meskes wrote: > > The other option I can see, albeit without looking into details, is > > allowing all comments and then testing it for the right syntax > > after > > parsing. This could potentially also solve the above mentioned > > option > > problem. > > This idea sounds great. But I am not sure that I can understand it > correctly. > > I understood the concept of this idea as following. Is it right? > 1. The parser ignores comments/*...*/ as usual. That is, parser does > not > identify comments as a token. I guess it'd be easier to accept each comment as a token and then parse the token text afterwards. > 2. After parsing, we parse again only to extract comments. Not sure if we can do that without creating a lot of overhead. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Keep ECPG comment for log_min_duration_statement
> As I said in the first e-mail, there are some restrictions of comment > position in my implementation. I am concerned that an error will > occur in .pgc files users made in old version. > So, this feature should be a new option. I see, this makes sense. > When the pre-compiler(ECPG) converts C with embedded SQL to normal C > code, gram.y is used for syntactic analysis. I need to change gram.y > for comments in SQL statement. > But I do not come up with better idea that gram.y is not affected. > If you are interested in my implementation in detail, please check > the [WIP]patch I attached. I'm not sure we would want to change the backend parser for something only used in ecpg. Actually I'm pretty sure we don't. I can see two possible solutions. One would be to replace the parser rules. Please see parse.pl for details. Some rules are already replaced by ecpg specific ones. However, the more rules we replace the more manual syncing effort we need for changes in gram.y. The other option I can see, albeit without looking into details, is allowing all comments and then testing it for the right syntax after parsing. This could potentially also solve the above mentioned option problem. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Keep ECPG comment for log_min_duration_statement
Hi, > So, I'd like to modify ecpg command not to remove some specific > comments. > ... > [Interface] > add a new option "--enable-parse-comment" to ecpg command. > > ecpg --enable-parse-comment ,..., prog.pgc > > This option enables ecpg command to pass on block comments (/* 〜 */) > to converted C file. The reason for not keeping the comments in the statement was simply to make the parser simpler. If you added this feature, do we still see a reason for keeping the old version? Or in other words, shouldn't we make the "enable-parse-comment" version the default without a new option? Michael -- Dr. Michael Meskes, Geschaeftsfuehrer/CEO Tel.: +49 (0)2166 / 99 01 0 E-Mail: michael.mes...@credativ.com IM: m...@jabber.credativ.com PGP: BBBC 58B4 5994 CF9C CC56 BCDA DF23 DA33 9697 8EB3 credativ international GmbH, HRB Moenchengladbach 15543, Trompeterallee 108, 41189 Moenchengladbach, Germany Geschaeftsfuehrung: Dr. Michael Meskes, Joerg Folz == Global: http://credativ.com Germany:http://credativ.de Netherlands:http://credativ.nl India: http://credativ.in UK: http://credativ.co.uk USA:http://credativ.us == -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [WIP] RE: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG
Hi Ideriha-san, > I created a patch. Thank you. Would it be possible for you to re-create the patch without the white-space changes? > I marked [WIP] to the title because some documentation is lacked and > format needs some fixing. I noticed that the docs say the statement is a PostgreSQL addon. However, I think other databases do have the same statement, or don't they? 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [bug fix] Trivial ecpg bug which can cause memory overrun
Hi, > While investigating some other issue, we found a trivial bug of > ecpg. The attached is a fix for that. > ... Thanks for spotting 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 meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Fix typo in ecpg.sgml
> there is a missing "EXEC" in ecpg.sgml in the list of transaction > management commands. Right, and the "SQL" was missing, too. Thanks for spotting, fixed in 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 org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG
> I wanted to say that in order to use the connection pointed > by the DECLARE STATEMENT some functions like ECPGdo() would be > modified or > new function would be added under the directory ecpglib/. > > This modification or new function will be used to get the connection > by statement_name. Ah, now I understand. Thank you for your explanation. I'm looking forward to seeing 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] DECLARE STATEMENT setting up a connection in ECPG
> [System Design Plan] > To support above functionality, ecpg precompiler should support: > - To understand the DECLARE STATEMENT syntax Already does, albeit as a noop. > - Translate the DECLARE STATEMENT into a new function with parameters. >These parameters carry the information like connection_name and > statement_name. > - The function is a new function defined in the ECPG library. Why's that? I haven't checked if the standard says anything about this and my memory might be wrong, but isn't "DECLARE STATEMENT" supposed to be purely declarative, i.e. not executed at run time? 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Let's get rid of the separate minor version numbers for shlibs
> The only place where we'd have a problem is the ecpg preprocessor > itself, which is scheduled to be at version 4.13 this year. However, > that version number is purely cosmetic since AFAICS the only thing > that gets done with it is to print it in response to -v and suchlike. > I don't really see why ecpg has its own version number anyway --- > why don't we go over to giving it the same version number as the > rest of PG? So it would just print the PG_VERSION string in the > places > where it currently prints the numbers hard-wired in > ecpg/preproc/Makefile. Absolutely agreed. The current numbering is historical but does not seem to make sense anymore. Besides, the main usage I see is that you can see which preprocessor version was used to create a certain C file. With the preprocessor's parser being auto-generated having the PG version makes much more sense IMO. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question and suggestion about application binary compatibility policy
> However, the problem I pointed out is that when the new library is > incompatible with the older one, say the major version of libpq.dll > changes from 5 to 6, the application user and/or developer cannot > notice the incompatibility immediately and easily. On Unix/Linux, > the application fails to start because the older library is not > found. On the other hand, the application will start on Windows and > probably cause difficult trouble due to the incompatibility. I don't think this is a very good situation, but I have no idea if this can be solved. However, I'd prefer a technical solution over a documentation one. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question and suggestion about application binary compatibility policy
> I couldn't find appropriate system documentation. Regarding Linux, I > remember I saw some HOWTO on tldp.org website which explains the > concept of shared library soname, but it's not very friendly for > users who just want to know the application binary compatibility > policy of PostgreSQL. And I don't think there's suitable I would expect Unix sysadmins to understand that howto, but there are others, e.g. a random hit from google: https://www.bottomupcs.com/libra ries_and_the_linker.xhtml There even is a wikipedia page about it: https://en.wikipedia.org/wiki/ Soname > documentation on Windows. Even if there is any, users will not be > sure whether PostgreSQL follows those platform-specific > conventions. They may have doubts about it, because even the product > version "PostgreSQL x.y.z" causes misconception that x is the major > version and y is the minor one. I don't know anything about the Windows setup in PostgreSQL, but I would find it fair to assume that PostgreSQL follows conventions. > BTW, although this may be a separate topic, it may be better that we > add the major version in the library names like libpq5.dll and > libecpg6.dll, so that the application can fail to run with the > incompatible versions of libpq and libecpg. FYI: Does this mean you cannot have to versions of libpq installed on the same Windows system at the same time? 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question and suggestion about application binary compatibility policy
> > Sorry I fail to understand what you mean with "legal"? Are you > > wondering > > about license restrictions? There are none. > > Sorry, I just meant "correct" or "valid". Ah ok, thanks for clarifying. > > As for compatibility, that's what major version numbers are for. > > This is > > not a PostgreSQL topic, but a general system one as for instance > > the same > > holds for libc. > > Yes, but Windows users probably don't understand or know it. So, I > suggested explicitly describing the application binary compatibility > policy in the PostgreSQL manual. What do you think about it? Couldn't you point your customer to the system documentation? Personally I don't think standard system behavior should be documented for each application relying on it but ymmv. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question and suggestion about application binary compatibility policy
Hi, > - Build an embedded SQL C application with PostgreSQL 9.2. > - Distribute the app without ecpg nor libpq libraries. Require users > to install PostgreSQL client which includes ecpg and libpq libraries. > - Use the app with newer PostgreSQL major versions without rebuilding > the app. That is, the users just replaces the PostgreSQL client. > > I expect this is legal, because the so_major versions of ecpg and > libpq are 6 and 5 respectively for all PostgreSQL 9.x versions so > far. However, I could not find any description of this binary > compatibility policy in the manual, so I haven't been able to answer > the customer. Sorry I fail to understand what you mean with "legal"? Are you wondering about license restrictions? There are none. As for compatibility, that's what major version numbers are for. This is not a PostgreSQL topic, but a general system one as for instance the same holds for libc. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NOT EXIST for PREPARE
> I want to understand the situation. You may want to make the build > ecpg > optional. Personally, I want to. You lost me here, sorry. What exactly do you want to do? While ecpg may not be the choice for new applications, there are a lot of legacy applications out there that need ecpg to be migrated to PostgreSQL. So I think, completely removing it is out of the question. An optional build does not change a thing because it still has to compile et al. If you mean you'd like to decouple it from the backend build, that one is difficult because the parser is supposed to accept exactly the same SQL. And we spend quite a bit of effort to make it auto-build from the backend parser to make sure we don't lose any changes. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] NOT EXIST for PREPARE
> PS Who use ecpg? For me it's like hell. More than you think. I doubt you want to propose removing features that make developing new features harder, or do 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 Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] backpatch for REL9_4_STABLE of commit 40482e606733675eb9e5b2f7221186cf81352da1
On Mon, Feb 08, 2016 at 09:20:46AM +, Huong Dangminh wrote: > I think this fixed is also required for REL9_4_STABLE. > Please confirm the attached patch. Sure thing, no idea where that cherry-pick got lost. 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! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Warnings around booleans
Playing around a bit lead to to find that this is caused by a wrong type declaration in two places. 'isarray' is declared as bool instead of enum ARRAY_TYPE in two places. This appears to be an oversight, perhaps caused by the boolean sounding name. I vaguely remember that it used to be bool back in the day. Does this look right to you? If so, will you apply it? Yes and yes. Thanks for spotting, fixed in master and the back branches. 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.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Collection of memory leaks for ECPG driver
On Sat, Jun 13, 2015 at 12:02:40AM -0400, Tom Lane wrote: But having said that, I would not be in a hurry to remove any existing if-guards for the case. For one thing, it makes the code look more similar to backend code that uses palloc/pfree, where we do *not* allow pfree(NULL). There's also the point that changing longstanding code creates back-patching hazards, so unless there's a clear gain it's best not to. Makes sense, but there is no point in adding hos if-guards to old code that doesn't have it either,right? 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.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Collection of memory leaks for ECPG driver
On Mon, Jun 08, 2015 at 10:50:25PM +0900, Michael Paquier wrote: And the caller needs to be sure that str actually allocates enough space.. That's not directly ECPG's business, still it feels But there is no way for us to fix this as we want to implement the API as defined in Informix. uncomfortable. I fixed it with the attached. Thanks, committed. The world is full of surprises, and even if free(NULL) is a noop on modern platforms, I would rather take it defensively and check for a NULL pointer as Postgres supports many platforms. Other code paths tend to do already so, per se for example ECPGconnect. Right, that's because they were developed before free received the safeguard, or the programmer simply didn't know at that point in time. Unless I'm mistaken we have other code that only calls free() without an additional safeguard, so why shuld ecpglib be special? If you don't like it using both approaches, feel free to remove the check in the other case. :) More seriously, though, does anyone know of any platform where free(NULL) is *not* a noop? I don't like adding stuff just because of the world being full of surprises. There may also be other functions not working as advertized. Wouldn't that then mean we cannot use any function nor provided by ourselves? Perhaps I am overdoing it. I would have them for correctness (some other code paths do so) but if you think that the impact is minimal there then I am fine to not modify descriptor.c. Sorry, I wasn't referring to descriptor.c but to the whole preproc/ subtree. But as I already said, since we went through the effort we can of course apply it. Will be in my next push. 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.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Collection of memory leaks for ECPG driver
On Mon, Jun 08, 2015 at 01:57:32PM +0900, Michael Paquier wrote:
Please find attached a patch aimed at fixing a couple of memory leaks
in the ECPG driver. Coverity (and sometimes I after reading some other
code paths) found them.
And some are not correct it seems. But then some of the code isn't either. :)
diff --git a/src/interfaces/ecpg/compatlib/informix.c
b/src/interfaces/ecpg/compatlib/informix.c
index d6de3ea..c1e3dfb 100644
--- a/src/interfaces/ecpg/compatlib/informix.c
+++ b/src/interfaces/ecpg/compatlib/informix.c
@@ -672,6 +672,7 @@ intoasc(interval * i, char *str)
if (!str)
return -errno;
+ free(str);
return 0;
}
This function never worked it seems, we need to use a temp string, copy it to
str and then free the temp one.
diff --git a/src/interfaces/ecpg/ecpglib/connect.c
b/src/interfaces/ecpg/ecpglib/connect.c
index 55c5680..12f445d 100644
--- a/src/interfaces/ecpg/ecpglib/connect.c
+++ b/src/interfaces/ecpg/ecpglib/connect.c
@@ -298,7 +298,8 @@ ECPGconnect(int lineno, int c, const char *name, const
char *user, const char *p
envname = getenv(PG_DBPATH);
if (envname)
{
- ecpg_free(dbname);
+ if (dbname)
+ ecpg_free(dbname);
dbname = ecpg_strdup(envname, lineno);
}
This is superfluous, at least with glibc. free()'s manpage clearly says If
ptr is NULL, no operation is performed., so why should we check again? Or do
we have architectures where free(NULL) is not a noop?
diff --git a/src/interfaces/ecpg/preproc/descriptor.c
b/src/interfaces/ecpg/preproc/descriptor.c
index 053a7af..ebd95d3 100644
--- a/src/interfaces/ecpg/preproc/descriptor.c
+++ b/src/interfaces/ecpg/preproc/descriptor.c
Do we really have to worry about these in a short running application like a
precompiler, particularly if they add more than a simple free() command?
But then, you already did the work, so why not. Anyway, please tell me if you
want to update the patch or if I should commit whatever is clear already.
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.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)
[Sorry for being late to the party, travelling does take away too much time sometimes.] On 19.05.2015 21:04, Greg Sabino Mullane wrote: Bruno Harbulot asked for a devil's advocate by saying: My main point was that this is not specific to JDBC. Considering that even PostgreSQL's own ECPG is affected, the issue goes probably deeper than it seems. I'm just not convinced that passing the problem onto connectors, libraries and ultimately application developers is the right thing to do here. Well, one could argue that it *is* their problem, as they should be using the standard Postgres way for placeholders, which is $1, $2, $3... As Bruno already pointed out one could also argue that they just try to accept what the standard asked them for. I fail to see how such a way of arguing brings us closer to a solution, 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.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)
available as soon as 9.6 came out. But from the perspective of a driver author who has to support queries written by other people, the problem would not be gone for at least ten years more. Changing the driver's behavior sounds like a more practical solution. Even if it means breaking the standard? 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.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problems with question marks in operators (JDBC, ECPG, ...)
As far, as I can tell, question mark operators are also incompatible with PostgreSQL's ECPG when using dynamic SQL. http://www.postgresql.org/docs/current/static/ecpg-dynamic.html (I'm pasting an example at the end of this message, tried with a PostgreSQL 9.4 server.) Indeed it is. The question mark is used in ecpg to denote a variable to be filled-in by the process. I'm not completely sure if this was in the standard or only implemented because several (not sure if all) other precompiler used it as well. 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.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows
When running the test suite of ecpg, build generates a set of obj files and it happens that those files are not ignored in the code tree. 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 at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows
Actually, if we are supporting toolchains that generate *.obj files, I'd expect the top-level .gitignore to ignore them, as it does *.o. But if that's the issue why have we not heard complaints before? ... +1 for adding a top level .gitignore entry. I don't have a Windows system to test on, but how come these files were only created in the ecpg testsuite? With the global .gitignore not mentioning *.obj it appears those files are not created anywhere else. Is the build process different for the rest of the tree? 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Object files generated by ecpg test suite not ignored on Windows
On 09.03.2015 16:58, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: The MSVC build creates project directories which contain all the .obj files etc. The file locations for intermediate artefacts are quite different from the way a Unix build works. There is an ignore rule for these directories, which covers the .obj files there. But ecpg files are generated like in Unix builds. Ah. That's lots more plausible than no one's ever done any development on Windows. I can believe that not so many people have run the ecpg tests there. Completely agreed. Since we have a global ignore rule for .o files it makes plenty of sense to have one for .obj files also. Certainly better than have one rule for each ecpg test case. Agreed. So we should revert the previous patch ... Done. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Dereferenced pointer checks in data.c of ECPG
A patch is attached, and the issue has been spotted by Coverity. Regards, Thanks, 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ecpg array support, or lack thereof
On Wed, Feb 04, 2015 at 10:07:07AM -0500, Tom Lane wrote:
Michael Meskes would be the authority on that question, so I've cc'd
him to make sure he notices this thread ...
Thanks Tom.
The leaks were in the code that takes a host variable, and converts it
into a string for sending to the server as a query parameter. In
particular, it was in code that deals with arrays. However, the fine
manual says:
SQL-level arrays are not directly supported in ECPG. It is not
possible to simply map an SQL array into a C array host variable.
This will result in undefined behavior. Some workarounds exist,
however.
That very clearly says that the code that was fixed is not actually
supported.
It seems quite possible to me that this manual text is out of date.
It is, at least partly.
1. In timestamp, interval, and date, the array offset is calculated
incorrectly:
Same for numeric it seems.
2. The constructed array looks like this (for timestamp):
array [2005-06-23 11:22:33,2004-06-23 11:22:33]
That's bogus. It's sent as a query parameter, not embedded into an SQL
string, so the syntax should be '{...}'.
Right. Now I can imagine that this is due to changes over the years. What
worries my, though, is that this was fixed for integers, but only for integers,
not even for short or long variants thereof. No idea how that happened.
It would be nice to fix these, and add a test case to cover all kinds of
arrays. Although technically, it works as advertised, because the manual
says that it will result in undefined behaviour.
:)
At the very least it should cover the different types that actually get code
copied and pasted.
I'm on it as my time permits.
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, PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Unlikely-to-happen crash in ecpg driver caused by NULL-pointer check not done
On Tue, Feb 03, 2015 at 10:44:17PM +0900, Michael Paquier wrote: All those things are addressed in the patch attached. Fixed a typo and commited. Thanks Michael for fixing and Heikki for reviewing. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal for better support of time-varying timezone abbreviations
On Wed, Oct 22, 2014 at 11:32:41AM -0400, Tom Lane wrote: I don't have a strong opinion about which of the above things to do ... what's your preference? I think it's better for the future if me make a clean cut. Yes, the option keeps compatability a little bit higher, but that doesn't matter that much as the codes won't be used by the server anyway. Besides, they may eventually change and then we have to make sure to remember ecpg's copy again. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal for better support of time-varying timezone abbreviations
On Wed, Oct 15, 2014 at 09:50:16AM -0400, Tom Lane wrote: The same thought had occurred to me. Probably the main use of the datetime parsing code in ecpg is for interpreting outputs from the server, and (at least by default) the server doesn't use timezone abbreviations when printing timestamps. So maybe that's largely dead code anyhow. I would not propose back-patching such a change, but we could try it in 9.5 and see if anyone complains. Agreed on all accounts. A less drastic remedy would be to remove just those abbreviations whose meaning has actually changed over time. Eventually that might be all of them ... but in the meantime, we could at least argue that we weren't breaking any case that worked well before. This is what your patch did, right? 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposal for better support of time-varying timezone abbreviations
On 15.10.2014 00:26, Tom Lane wrote: * I've not touched ecpg except for cosmetic changes to keep the struct definitions in sync, and to fix the previously-mentioned bogus free() attempt. I doubt that it would be worth teaching ecpg how to access the zic timezone database --- the problem of configuring where to find those files seems like more trouble than it's worth given the lack of complaints. I'm not sure what we should do about the obsolete timezone abbreviations in its table. Maybe we should just remove thme for the new release. Yes, that might break some applications, but then the server doesn't know these either, so the applications might break 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 Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] using array of char pointers gives wrong results
PFA patch ecpg_char_ptr_arr.patch to fix this issue. It has changes as follows ... Thanks for finding and fixing the problem. Patch applied to complete 9 series with only a minor 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 Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: ECPG FETCH readahead
Thanks an awful lot Antonin. Committer availability might well be the issue, but missing review probably too. Yes, you're right. If my taks is mostly one last glance and a commit I will make time for that. Whether this review is enough to move the patch to ready for committer - I tend to let the next CFM decide. (I don't find it productive to ignite another round of discussion about kinds of reviews - already saw some.) I saw some remarks in your review that Zoltan wants to address. Once I got the updated version I'll have a look at it. Zoltan, could you send a new version by end of day tomorrow? I'll be sitting on a plane for a longer time again on Saturday. :) 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Pointer to structure in ECPG
Thanks Ashutosh, both patches committed and backported to the whole 9.* series. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] using arrays within structure in ECPG
On Wed, Apr 02, 2014 at 09:33:15AM +0530, Ashutosh Bapat wrote: So, you are saying that we should try to catch such errors and report during pre-compile time. That's better than silently corrupting the data. Well, I think this goes without saying. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] using arrays within structure in ECPG
On Wed, Apr 02, 2014 at 05:49:03PM +0530, Ashutosh Bapat wrote: I have one more doubt, regarding offsets. ... This is actually a very good question. Parts of this code are older than my work on ecpg, meaning they were already in version 0.1. It could very well be that with some changes over the years this test isn't needed anymore. The regression suite works without just nicely. To be honest, the whole type.c code needs a real rewrite to be better legible. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] using arrays within structure in ECPG
Hi Ashutosh, I tried to fix the offset problem. PFA the patch. It does solve the problem of setting wrong offset in ECPGdo() call. Thanks, looks correct to me. But then there is problem of interpreting the result from server as an array within array of structure. The problem is there is in ecpg_get_data(). This function can not understand that the field is an array of integers (or for that matter array of anything) and store all the values in contiguous memory at the given address. I guess I know where that comes from, without actually looking at the code, though. Nested arrays are not supported by ecpg and the precompiler spits out an error message, just check preproc/type.c. However, in your example you have the struct essantially sandwiched between the arrays and the (too) simple check in that file doesn't notice, but because the implementation is nevertheless lacking. I'm sorry, but this sounds like a missing feature bug. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] using arrays within structure in ECPG
On Mon, Mar 24, 2014 at 11:52:30AM +0530, Ashutosh Bapat wrote: For all the members of struct employee, except arr_col, the size of array is set to 14 and next member offset is set of sizeof (struct employee). But for arr_col they are set to 3 and sizeof(int) resp. So, for the next row onwards, the calculated offset of arr_col member would not coincide with the real arr_col member's address. Am I missing something here? No, this looks like a bug to me. I haven't had time to look into the source codebut the offset definitely is off. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG regression tests generating warnings
On Sun, Jan 12, 2014 at 08:28:57AM -0800, Kevin Grittner wrote: desc.pgc:55: WARNING: descriptor outdesc does not exist desc.pgc:86: WARNING: descriptor outdesc does not exist Thanks, I didn't notice, fixed. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] preproc.c compilation error
You have to rebuild the auto-generated pgc.c, preproc.c and preproc.y or simply remove them to force a rebuild. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [bug fix] ECPG app crashes due to SIGBUS on SPARC Solaris
On Sun, Jan 05, 2014 at 03:42:42PM +0900, MauMau wrote: I ran the ECPG regression test with the unpatched 64-bit PostgreSQL 9.2.4 on SPARC Solaris, and it succeeded (all 54 tests passed). For ... Thanks a lot. Patch applied to HEAD and all the backbranches. Will push shortly. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [bug fix] connection service file doesn't take effect with ECPG apps
On Sun, Dec 29, 2013 at 05:35:22AM +0900, MauMau wrote: Your test case seems different from my original mail. In my test As it turned out that wasn't the problem. It was simple typo on my side. Sorry for the hassle. However, I'd prefer to solve the problem slightly differently by not creating an empty host variable instead of checking for it after the fact. But I take it you don't mind that. Fixed in HEAD and all back branches. Thanks for the report. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [bug fix] connection service file doesn't take effect with ECPG apps
On Sat, Dec 28, 2013 at 04:37:44PM +0900, MauMau wrote: You can confirm it by adding the following code fragment to ecpglib/connect.c. The attached file contains this. ... Sorry for not being precide enough. I did run some tests and it works like a charm for me. Or in other words, I used the connect command you had in your email with a services file pointing to a local database and it connected to that database. Instead of adding an additional output I checked the log output which suggested that host was NULL. While I cannot see how your patch could do any harm, I'd still like to figure out why I don't see the same behaviour. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [bug fix] ECPG app crashes due to SIGBUS on SPARC Solaris
On Sat, Dec 28, 2013 at 08:04:09AM +0900, MauMau wrote: OK, I'll run the ECPG regression test on Solaris without the patch. Please wait until Jan 6 2014 or so, because we've just entered new year holidays here in Japan. Sure, we're no in a particular hurry. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [bug fix] connection service file doesn't take effect with ECPG apps
On Tue, Dec 17, 2013 at 09:26:49PM +0900, MauMau wrote: [Problem] The ECPG app runs the statement: EXEC SQL CONNECT TO 'tcp:postgresql://?service=my_service'; ... ECPGconnect() parses the URI and produces an empty host name. It passes an empty string as the value for host connection parameter to PQconnectdbParams(). Interestingly enough it works flawlessly on my system. Any idea where the empoty host name comes from? Before accepting the patch I'd like to find out why you got an empty host variable and I don'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 Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [bug fix] ECPG app crashes due to SIGBUS on SPARC Solaris
On Tue, Dec 24, 2013 at 09:55:45PM +0900, MauMau wrote: The attached ECPG app crashes and dumps core with SIGBUS on Solaris for SPARC. I used Solaris 10, and Oracle Studio to compile the app for 64-bit build. The same app completes successfully on Linux and Windows for x86/x564. What happens to the regression test suite on your system? There are test cases that access a descriptor in a similar way I think. Because desc1 is a char array, else block should be executed instead of the above path. Therefore, make ecpg pass SQL descriptor host variables to ECPGdo() with non-zero lengths. How did you decide which values to put in? I fail to see a reason for choosing exactly these values. Mkichael -- 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
On Thu, Nov 28, 2013 at 09:04:17AM +0100, Boszormenyi Zoltan wrote: Well, technically, unspecified means NO SCROLL according to the SQL standard. A lot of applications in ECPG are ported from other systems, That means by automatically adding a literal NO SCROLL to the command we obey standard, right? That's fine by me. behavior applies, but it might break existing apps that were unknowingly relying on a simple cursor being scrollable. OTOH any such app would be subject to breakage anyway as a result of planner changes, so it's hard to complain against this, as long as it's happening in a major version update. Ported applications might be in the same boat. I'm not sure if all other DBMSs stick with the standard if nothing is specified. So again, adding it might help make it clearer. Anyway, is explicitly adding NO SCROLL the preferred solution for everyone? +1 from 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 Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Building on S390
Hi, I spend some time trying to figure out why PostgreSQL builds on S390-Linux, but Postgres-XC doesn't. Well at least this holds for the Debian packages. So far I haven't figured it out. However, it appears to me that the build should fail for both. I'm not an S390 expert by any means, but I was told that S390 requires -fPIC and the build failure in the Debian package of XC came from a stray -fpic that was used together with -fPIC. But alas the PostgreSQL build has both as well. Anyway, I changed src/makefiles/Makefile.linux to include ifeq $(findstring s390,$(host_cpu)) s390 CFLAGS_SL = -fPIC else before setting CFLAGS_SL = -fpic et voila XC builds just fine on S390. So I wonder shouldn't we use -fPIC instead of -fpic for S390 in general? 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Building on S390
On Fri, Nov 22, 2013 at 11:27:45AM -0500, Tom Lane wrote: I think this is probably nonsense. I spent ten years maintaining Postgres for Red Hat, and I never saw any such failure on s390 in their packages. If -fpic weren't good enough for shared libraries on s390, how'd any of those builds get through their regression tests? You've got a point here. It may well be that *mixing* -fpic and -fPIC is a bad idea, but I'd say that points to an error in something XC is doing, because the core Postgres build doesn't use -fPIC anywhere for Linux/s390, AFAICS. I actually only compared to the Debian build which *does* have -fPIC and indeed it seems it adds -fPIC unconditionally. But then the PostgreSQL package works flawlessly which obviously points to XC for the problem. I give you that. Furthermore, if we change that convention now, we're going to increase the risk of such mixing failures for other people. Sure, but if this a bug we should. I'm not saying it is, I simply don't know. The thread is starting with my email here http://lists.debian.org/debian-s390/2013/10/msg8.html and the reply said: It uses -fpic instead of -fPIC. No, I'm not shortening that email reply here. :) Checking the Debian logs it appears that all calls use *both* which seems to do the right thing. And yes, it appears there is a change in XC that makes it break. But still, I would think there has to be a correct set of options. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] ecpg: Split off mmfatal() from mmerror()
On Tue, Nov 12, 2013 at 10:22:20PM -0500, Peter Eisentraut wrote: Similar to recent pg_upgrade changes (https://commitfest.postgresql.org/action/patch_view?id=1216), here is a patch to separate the terminating and nonterminating variants of mmerror() in ecpg. ... Haven't tried it, but it sure looks good to me. Feel free to commit. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] gcc 4.8 compiler warning in ecpg check
On Sat, Nov 02, 2013 at 02:25:17PM -0400, Peter Eisentraut wrote: This could be removed, but is it something that is actually part of what is being tested? Thanks for spotting Peter. Yes, this should have been used. I just committed a fix. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.3 bug fix] ECPG does not escape backslashes
On Fri, Jul 05, 2013 at 09:41:26AM -0400, Tom Lane wrote: Um ... 9.3 is a separate branch now, please fix it there also. Done. Seems I missed a new branch - yet again. Sorry and thanks for pointing it out 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 Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.3 bug fix] ECPG does not escape backslashes
On Fri, Jul 05, 2013 at 08:08:06AM -0400, Andrew Dunstan wrote: This looks incomplete. Surely just escaping backslashes alone is not enough. I suspect at least the char and any chars below 0x20 should be quoted also. The char I just added, however, my tests did bring up any problem with chars below 0x20. If anybody sees another character breaking ecpg, please tell me and I'll fix 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 Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.3 bug fix] ECPG does not escape backslashes
On Wed, Jul 03, 2013 at 07:22:48PM +0900, MauMau wrote: not specific to 9.3. Could you commit and backport this? Committed to 8.4, 9.0, 9.1, 9.2 and HEAD. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.3 bug fix] ECPG does not escape backslashes
On Fri, Jul 05, 2013 at 08:08:06AM -0400, Andrew Dunstan wrote: This looks incomplete. Surely just escaping backslashes alone is not enough. I suspect at least the char and any chars below 0x20 should be quoted also. Right, this didn't even occur to me, but there are surely more characters that need to be escaped. Gotta dig into this. Thanks for pointing this out. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.3 bug fix] ECPG does not escape backslashes
On Wed, Jul 03, 2013 at 07:22:48PM +0900, MauMau wrote: I happened to find a trivial bug of ECPG while experimenting with 9.3 beta 2. Please find attached the patch to fix this. This is not specific to 9.3. Could you commit and backport this? This appears to be Windows specific. I don't have a Windows system to test with. How does Visusal Studio handle #line entries with full path names? Are they all escaped? Or better do they have to be? This is necessary not only on Windows but also on UNIX/Linux. For your information, running gcc -E di\\r/a.c escapes \ and outputs the line: # 1 di\\r/a.c Now this statement surprises me: michael@feivel:~$ ecpg testa/init.pgc michael@feivel:~$ grep line testa/init.c |head -1 #line 1 test\\a/init.pgc michael@feivel:~$ gcc -o i testa/init.c -I /usr/include/postgresql/ -l ecpg michael@feivel:~$ This seems to suggest that it works nicely on Linux. So what do ou mean when saying the problem also occurs on Linux? 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.3 bug fix] ECPG does not escape backslashes
On Thu, Jul 04, 2013 at 07:58:39AM -0400, Andrew Dunstan wrote: michael@feivel:~$ grep line testa/init.c |head -1 #line 1 test\\a/init.pgc ... Really? I'd expect to see 4 backslashes in the #line directive, I think. Eh, why? The four backslashes come are two that are escaped for shell usage. The directory name is in my example was test\\a. What did I miss? 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.3 bug fix] ECPG does not escape backslashes
On Thu, Jul 04, 2013 at 03:18:12PM +0200, Andres Freund wrote: Previous versions of CPP did not interpret escapes in ‘#line’; we have changed it because the standard requires they be interpreted, and most other compilers do.« So that means MauMau was right and backslashes have to be escaped in filenames in #line directives, right? Apparently my examples were badly chosen as I didn't see an error no matter how many backslashes I had. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List
On Tue, Jul 02, 2013 at 04:00:22PM -0400, Robert Haas wrote: make you review patches against your will. Don't take it for more than what Josh meant it as. And that was what? 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List
On Tue, Jul 02, 2013 at 09:42:43PM -0700, Josh Berkus wrote: Clearly I ticked off a bunch of people by publishing the list. On the other hand, in the 5 days succeeding the post, more than a dozen additional people signed up to review patches, and we got some of the ready for committer patches cleared out -- something which nothing else I did, including dozens of private emails, general pleas to this mailing list, mails to the RRReviewers list, served to accomplish, in this or previous CFs. So your saying the end justifies the means? I beg to disagree. So, as an experiment, call it a mixed result. I would like to have some other way to motivate reviewers than public shame. I'd like to have Doesn't shame imply that people knew that were supposed to review patches in the first place? An implication that is not true, at least for some on your list. I think I better not bring up the word I would describe your email with, just for the fear of mistranslating 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 Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List
On Wed, Jul 03, 2013 at 09:47:13AM -0400, Robert Haas wrote: An attempt to prod a few more people into helping review. I can see that this pissed you off, and I'm sorry about that. But I don't think that was his intent. I hoped for this kind of answer from him but ... 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List
On Wed, Jul 03, 2013 at 04:03:08PM -0400, Bruce Momjian wrote: I do understand Josh's frustration that something different had to be done. As a matter of fact I do, too. I just think the style of blaming people in public like this is not ideal. As I said I didn't even notice this email in the first hand until I was approached from other people and called a slacker in communication not related to the CF at all. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List
On Wed, Jul 03, 2013 at 12:34:50PM -0700, Josh Berkus wrote: If you didn't feel obligated, you wouldn't be pissed at me. You'd just blow it off (like Bruce did). I think you're angry with me because you feel guilty. That is outrageous bullshit! My *personal* viewpoint is that all committers should feel obligated to And my *personal* viewpoint is that nobody should be offended like this. But apparently I don't get my wish either. review and commit patches from other contributors. That's why they're committers in the first place. Certainly if a committer looks at the CF application and notices that 80% of the reviewing and committing is being done by three people, none of whom have any more spare time than they do, they should feel obligated to help those people out. How many patches did you review? You don't have to be a committer to do that. We have a problem with patch reviewing and committing in this project; it's not being done in a timely fashion in general (every CF last year ended late), and the people who are doing most of the work feel overworked and frustrated. This problem is getting worse every year, and will kill the project if it continues on its current trajectory. As if publicly blaming people for not behaving the way you would like them to will do the project a lot of good. Let me stress again that you didn't even try talking to the people in question in private before, nor did you bother putting your *suggestion* up for discussion before flaming people. Also let me stress again that I did *not* put a patch into the CF. 3) getting most of our existing contributors to shoulder their fair share of patch review. (3) is what I'm addressing on this thread. The reason I volunteered to be CFM this time was directly because of our discussion in Ottawa of how the review process wasn't working. I decided to find out *why* it wasn't working, and the first obvious thing I ran across was that most of our current and our long-term contributors weren't doing any patch review. For CF1, the number of people submitting patches outnumbered those who had volunteered for review 2 to 1. That *is* the review problem in a nutshell; everybody wants someone else to do the work. Great, I wasn't part of any discussion as I didn't make it to Ottawa this time. Neither am I part of the problem with 0 patches, but still I've got to shoulder the blame in a less than friendly way. I don't think it's too much to ask people who are listed on the project developers page as major contributors to review one patch per CommitFest most of the time. If they did just *one* it would substantially decrease the workload on the people who are currently doing the vast majority of review and commit. You didn't ask! You blamed and offended people! I won't go into details here because frankly why I have no time for reviewing a patch is none of your business. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.4 CF 1] The Commitfest Slacker List
Sorry for joining the thread this late, but I didn't really expect to see myself listed as a slacker on a public list. Additionally, the following committers are not listed as reviewers on any patch. Note that I have no way to search which ones might be *committers* on a patch, so these folks are not necessarily slackers This means I'm a slacker because I'm not reviewing or committing a patch, right? Do we have a written rule somewhere? Or some other communication about this? I would have liked to know this requirement before getting singled out in public. Also I'd like to know who made the decision to require a patch review from each committer as I certainly missed it. Was the process public? Where can I find more about it? In general I find it difficult to digest that other people make decisions about my spare time without me having a word in the discussion. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [9.3 doc fix] ECPG VAR command does not describe the actual specification
Looking around the 9.3 doc, I found a small, but not-insignificant error in the documentation. Thanks for finding and fixing. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in tm2timestamp
On Mon, Mar 04, 2013 at 05:08:26PM -0300, Alvaro Herrera wrote: Another point worth considering is that most of this is duplicated by ecpg's libpgtypes. Do we want to fix that one too, or do we just let it continue to be broken? I note that other bugs are already unfixed in ecpg's copy. One other idea to consider is moving these things to Meaning that a fix wasn't put there, too? But in light of this bug and other already fixed date/time bugs, perhaps it's warranted? Opinions please. I'd love to go to a single source. Most of libpgtypes was taken from the backend back when it was developed. 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bug in tm2timestamp
On Mon, Mar 04, 2013 at 05:55:26PM -0300, Alvaro Herrera wrote: error codes for the caller to figure out. Maybe we could create a layer on top of ereport, that gets both the error message, sqlstate etc, and ... Couldn't we just create ecpg's own version of ereport, that does the right thing for ecpg? 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, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] COPY foo FROM STDOUT and ecpg
On Tue, Feb 26, 2013 at 07:24:44PM +0200, Heikki Linnakangas wrote: IIRC this check 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. Just less code to maintain. And it's strange to forbid something in ecpg grammar that the backend accepts, as a matter of principle. Na, I was talking about copying from STDOUT and to STDIN. Even if this is a very old feature I think we should fix 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 Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
