Re: [HACKERS] CommitFest 2009-09, two weeks on
On Nov 13, 2009, at 8:06 AM, Michael Meskes wrote: On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote: If you want to submit patches in a series like this one, they need to be considered standalone, I think. The Linux kernel devs work differently than us here. Zoltan broke them up because Michael asked him to do so. Actually these patchsets add different features. I see no reason why they should be done as one patch. However, I haven't had the time to look into the latest ones, but at least that was the situation when I asked Zoltan to split the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL good morning, are there some pending technical issues with those patches or can we basically review and commit? many thanks, hans -- Cybertec Schönig Schönig GmbH Reyergasse 9 / 2 A-2700 Wiener Neustadt Web: www.postgresql-support.de -- 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] CommitFest 2009-09, two weeks on
2009/11/13 Hans-Jürgen Schönig h...@cybertec.at: On Nov 13, 2009, at 8:06 AM, Michael Meskes wrote: On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote: If you want to submit patches in a series like this one, they need to be considered standalone, I think. The Linux kernel devs work differently than us here. Zoltan broke them up because Michael asked him to do so. Actually these patchsets add different features. I see no reason why they should be done as one patch. However, I haven't had the time to look into the latest ones, but at least that was the situation when I asked Zoltan to split the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/Linux, PostgreSQL good morning, are there some pending technical issues with those patches or can we basically review and commit? *scratches head* How is anyone supposed to answer that question? It is in the process of reviewing them that one decides whether there are any technical issues... ...Robert -- 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] CommitFest 2009-09, two weeks on
Alvaro Herrera írta: Boszormenyi Zoltan escribió: Alvaro Herrera írta: I have applied this patch after some tinkering. I mainly added support for fetch_args: FORWARD opt_from_in name and BACKWARD opt_from_in name in ecpg.addons which apparently you forgot. Thanks. Your fix is correct if this patch is considered standalone. This means I have to re-post the later patches to fix the reject this fix causes in them. Yeah. BTW I don't think the rest of the pieces in this series make sense to apply separately, because they don't do anything useful by themselves (one of them introduces an unused function, what good is in that?). I think they should be submitted as a single patch. If you want to submit patches in a series like this one, they need to be considered standalone, I think. The Linux kernel devs work differently than us here. Dan started reviewing the dynamic cursorname patch. He looked at it in the original form and he said that he's not familiar with the ECPG code. I have drafted the docs for the generated ECPG grammar (it was applied mainstream by Michael shortly after being posted) and have split this patch in question to help Dan in the review. The patch pieces explain the various problems about the implementation. Is it really *that* apparent that I read too much LKML? :-D -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- 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] CommitFest 2009-09, two weeks on
Alvaro Herrera írta: Boszormenyi Zoltan escribió: I have split up (and cleaned up a little) the dynamic cursorname patch into smaller logical, easier-to-review pieces. Descriptions below. 1) 1a-unified-optfromin-fetch-ctxdiff.patch ecpg supports optional FROM/IN in FETCH and MOVE statements (mainly because it's required by Informix-compatibility). Unify core and ecpg grammar as per Tom Lane's suggestion. I have applied this patch after some tinkering. I mainly added support for fetch_args: FORWARD opt_from_in name and BACKWARD opt_from_in name in ecpg.addons which apparently you forgot. Thanks. Your fix is correct if this patch is considered standalone. This means I have to re-post the later patches to fix the reject this fix causes in them. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- 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] CommitFest 2009-09, two weeks on
Alvaro Herrera írta: Boszormenyi Zoltan escribió: 2) 1b-cursor_name-ctxdiff.patch name - cursor_name transition in core grammar and ecpg grammar. Currently it does nothing, it's a preparation phase. Depends on patch 1. Applied this part too. I cannot apply the other ones -- they belong to the ECPG maintainer. I hope I cleared his road a bit. Thanks and best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- 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] CommitFest 2009-09, two weeks on
Boszormenyi Zoltan escribió: Alvaro Herrera írta: I have applied this patch after some tinkering. I mainly added support for fetch_args: FORWARD opt_from_in name and BACKWARD opt_from_in name in ecpg.addons which apparently you forgot. Thanks. Your fix is correct if this patch is considered standalone. This means I have to re-post the later patches to fix the reject this fix causes in them. Yeah. BTW I don't think the rest of the pieces in this series make sense to apply separately, because they don't do anything useful by themselves (one of them introduces an unused function, what good is in that?). I think they should be submitted as a single patch. If you want to submit patches in a series like this one, they need to be considered standalone, I think. The Linux kernel devs work differently than us here. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] CommitFest 2009-09, two weeks on
On Thu, Nov 12, 2009 at 2:49 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Boszormenyi Zoltan escribió: Alvaro Herrera írta: I have applied this patch after some tinkering. I mainly added support for fetch_args: FORWARD opt_from_in name and BACKWARD opt_from_in name in ecpg.addons which apparently you forgot. Thanks. Your fix is correct if this patch is considered standalone. This means I have to re-post the later patches to fix the reject this fix causes in them. Yeah. BTW I don't think the rest of the pieces in this series make sense to apply separately, because they don't do anything useful by themselves (one of them introduces an unused function, what good is in that?). I think they should be submitted as a single patch. If you want to submit patches in a series like this one, they need to be considered standalone, I think. The Linux kernel devs work differently than us here. Zoltan broke them up because Michael asked him to do so. ...Robert -- 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] CommitFest 2009-09, two weeks on
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote: If you want to submit patches in a series like this one, they need to be considered standalone, I think. The Linux kernel devs work differently than us here. Zoltan broke them up because Michael asked him to do so. Actually these patchsets add different features. I see no reason why they should be done as one patch. However, I haven't had the time to look into the latest ones, but at least that was the situation when I asked Zoltan to split the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org VfL Borussia! Forca Barca! Go SF 49ers! Use: Debian GNU/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] CommitFest 2009-09, two weeks on
Boszormenyi Zoltan escribió: I have split up (and cleaned up a little) the dynamic cursorname patch into smaller logical, easier-to-review pieces. Descriptions below. 1) 1a-unified-optfromin-fetch-ctxdiff.patch ecpg supports optional FROM/IN in FETCH and MOVE statements (mainly because it's required by Informix-compatibility). Unify core and ecpg grammar as per Tom Lane's suggestion. I have applied this patch after some tinkering. I mainly added support for fetch_args: FORWARD opt_from_in name and BACKWARD opt_from_in name in ecpg.addons which apparently you forgot. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] CommitFest 2009-09, two weeks on
Alvaro Herrera alvhe...@commandprompt.com writes: I have applied this patch after some tinkering. Shouldn't there be a docs change in that commit? regards, tom lane -- 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] CommitFest 2009-09, two weeks on
Tom Lane escribió: Alvaro Herrera alvhe...@commandprompt.com writes: I have applied this patch after some tinkering. Shouldn't there be a docs change in that commit? True -- fixed. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] CommitFest 2009-09, two weeks on
Boszormenyi Zoltan escribió: 2) 1b-cursor_name-ctxdiff.patch name - cursor_name transition in core grammar and ecpg grammar. Currently it does nothing, it's a preparation phase. Depends on patch 1. Applied this part too. I cannot apply the other ones -- they belong to the ECPG maintainer. I hope I cleared his road a bit. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] CommitFest 2009-09, two weeks on
Robert Haas wrote: On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Do you have any sense of how soon you'll feel confident to commit either patch? I'm bad at estimating. Not this week for sure, and next week I'm traveling and won't be able to spend as much time on it as I am right now. If no new major issues are found, and all the outstanding issues are resolved by me or Simon by then, maybe the week after that. It's now the week after that, so unless you're in the process of typing that 'cvs commit' command, I'm going to move HS + SR out to the next CommitFest so that we can close this one out and stamp alpha2. No objections here. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] CommitFest 2009-09, two weeks on
On Thu, Oct 15, 2009 at 2:27 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Robert Haas wrote: On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Do you have any sense of how soon you'll feel confident to commit either patch? I'm bad at estimating. Not this week for sure, and next week I'm traveling and won't be able to spend as much time on it as I am right now. If no new major issues are found, and all the outstanding issues are resolved by me or Simon by then, maybe the week after that. It's now the week after that, so unless you're in the process of typing that 'cvs commit' command, I'm going to move HS + SR out to the next CommitFest so that we can close this one out and stamp alpha2. No objections here. OK, done. ...Robert -- 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] CommitFest 2009-09, two weeks on
On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Do you have any sense of how soon you'll feel confident to commit either patch? I'm bad at estimating. Not this week for sure, and next week I'm traveling and won't be able to spend as much time on it as I am right now. If no new major issues are found, and all the outstanding issues are resolved by me or Simon by then, maybe the week after that. It's now the week after that, so unless you're in the process of typing that 'cvs commit' command, I'm going to move HS + SR out to the next CommitFest so that we can close this one out and stamp alpha2. brief pause for objections will now ensue ...Robert -- 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] CommitFest 2009-09, two weeks on
Robert Haas wrote: On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Do you have any sense of how soon you'll feel confident to commit either patch? I'm bad at estimating. Not this week for sure, and next week I'm traveling and won't be able to spend as much time on it as I am right now. If no new major issues are found, and all the outstanding issues are resolved by me or Simon by then, maybe the week after that. It's now the week after that, so unless you're in the process of typing that 'cvs commit' command, I'm going to move HS + SR out to the next CommitFest so that we can close this one out and stamp alpha2. brief pause for objections will now ensue I have a question. When we register the postponed patches on the CF-Nov site again, which tag should be choosen? Needs Review? or Ready for Commiter? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- 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] CommitFest 2009-09, two weeks on
2009/10/14 KaiGai Kohei kai...@ak.jp.nec.com: Robert Haas wrote: On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Do you have any sense of how soon you'll feel confident to commit either patch? I'm bad at estimating. Not this week for sure, and next week I'm traveling and won't be able to spend as much time on it as I am right now. If no new major issues are found, and all the outstanding issues are resolved by me or Simon by then, maybe the week after that. It's now the week after that, so unless you're in the process of typing that 'cvs commit' command, I'm going to move HS + SR out to the next CommitFest so that we can close this one out and stamp alpha2. brief pause for objections will now ensue I have a question. When we register the postponed patches on the CF-Nov site again, which tag should be choosen? Needs Review? or Ready for Commiter? Needs Review. ...Robert -- 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] CommitFest 2009-09, two weeks on
On Thu, Oct 1, 2009 at 7:48 AM, Magnus Hagander mag...@hagander.net wrote: On Thu, Oct 1, 2009 at 04:11, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote: Magnus Hagander mag...@hagander.net wrote: I can certainly review the win32 encoding patch, but I was rather hoping for some comments from others on if we're interested in a win32 only solution, or if we want something more generic. Should we just go with the win32-only one for now? Yes, because Windows is only platform that supports UTF-16 encoding natively. I believe my patch is the best solution for Windows even if we have another approach for other platforms. Actually, I think a better argument is that since Windows will *never* accept UTF8 logging, and that's what most databases will be in, much of this patch will be required anyway. So I should probably review and get this part in while we think about other solutions *as well* for other platforms. Given the above, it seems that perhaps we could go ahead and apply this? ...Robert -- 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] CommitFest 2009-09, two weeks on
Itagaki Takahiro wrote:
The point is *memory leak* in dblink when a query is canceled or
become time-out. I think it is a bug, and my patch could fix it.
Please see if this works for you.
Joe
Index: dblink.c
===
RCS file: /opt/src/cvs/pgsql/contrib/dblink/dblink.c,v
retrieving revision 1.84
diff -c -r1.84 dblink.c
*** dblink.c 12 Sep 2009 23:20:52 - 1.84
--- dblink.c 4 Oct 2009 02:19:17 -
***
*** 97,109
static char *generate_relation_name(Oid relid);
static void dblink_connstr_check(const char *connstr);
static void dblink_security_check(PGconn *conn, remoteConn *rconn);
! static void dblink_res_error(const char *conname, PGresult *res, const char *dblink_context_msg, bool fail);
static char *get_connect_string(const char *servername);
static char *escape_param_str(const char *from);
/* Global */
static remoteConn *pconn = NULL;
static HTAB *remoteConnHash = NULL;
/*
* Following is list that holds multiple remote connections.
--- 97,111
static char *generate_relation_name(Oid relid);
static void dblink_connstr_check(const char *connstr);
static void dblink_security_check(PGconn *conn, remoteConn *rconn);
! static void dblink_res_error(const char *conname, const char *dblink_context_msg, bool fail);
static char *get_connect_string(const char *servername);
static char *escape_param_str(const char *from);
+ static void dblink_error_callback(void *arg);
/* Global */
static remoteConn *pconn = NULL;
static HTAB *remoteConnHash = NULL;
+ static PGresult *res = NULL;
/*
* Following is list that holds multiple remote connections.
***
*** 143,149
--- 145,154
do { \
msg = pstrdup(PQerrorMessage(conn)); \
if (res) \
+ { \
PQclear(res); \
+ res = NULL; \
+ } \
elog(ERROR, %s: %s, p2, msg); \
} while (0)
***
*** 212,217
--- 217,238
} \
} while (0)
+ #define ERRORCONTEXTCALLBACK \
+ ErrorContextCallback dberrcontext
+
+ #define PUSH_DBERRCONTEXT(_error_callback_) \
+ do { \
+ dberrcontext.callback = _error_callback_; \
+ dberrcontext.arg = (void *) NULL; \
+ dberrcontext.previous = error_context_stack; \
+ error_context_stack = dberrcontext; \
+ } while (0)
+
+ #define POP_DBERRCONTEXT \
+ do { \
+ error_context_stack = dberrcontext.previous; \
+ } while (0)
+
/*
* Create a persistent connection to another database
*/
***
*** 325,331
dblink_open(PG_FUNCTION_ARGS)
{
char *msg;
- PGresult *res = NULL;
PGconn *conn = NULL;
char *curname = NULL;
char *sql = NULL;
--- 346,351
***
*** 333,339
--- 353,361
StringInfoData buf;
remoteConn *rconn = NULL;
bool fail = true; /* default to backward compatible behavior */
+ ERRORCONTEXTCALLBACK;
+ PUSH_DBERRCONTEXT(dblink_error_callback);
DBLINK_INIT;
initStringInfo(buf);
***
*** 381,389
if (PQtransactionStatus(conn) == PQTRANS_IDLE)
{
res = PQexec(conn, BEGIN);
! if (PQresultStatus(res) != PGRES_COMMAND_OK)
DBLINK_RES_INTERNALERROR(begin error);
PQclear(res);
rconn-newXactForCursor = TRUE;
/*
--- 403,412
if (PQtransactionStatus(conn) == PQTRANS_IDLE)
{
res = PQexec(conn, BEGIN);
! if (!res || PQresultStatus(res) != PGRES_COMMAND_OK)
DBLINK_RES_INTERNALERROR(begin error);
PQclear(res);
+ res = NULL;
rconn-newXactForCursor = TRUE;
/*
***
*** 402,412
res = PQexec(conn, buf.data);
if (!res || PQresultStatus(res) != PGRES_COMMAND_OK)
{
! dblink_res_error(conname, res, could not open cursor, fail);
PG_RETURN_TEXT_P(cstring_to_text(ERROR));
}
-
PQclear(res);
PG_RETURN_TEXT_P(cstring_to_text(OK));
}
--- 425,437
res = PQexec(conn, buf.data);
if (!res || PQresultStatus(res) != PGRES_COMMAND_OK)
{
! dblink_res_error(conname, could not open cursor, fail);
PG_RETURN_TEXT_P(cstring_to_text(ERROR));
}
PQclear(res);
+ res = NULL;
+
+ POP_DBERRCONTEXT;
PG_RETURN_TEXT_P(cstring_to_text(OK));
}
***
*** 418,431
dblink_close(PG_FUNCTION_ARGS)
{
PGconn *conn = NULL;
- PGresult *res = NULL;
char *curname = NULL;
char *conname = NULL;
StringInfoData buf;
char *msg;
remoteConn *rconn = NULL;
bool fail = true; /* default to backward compatible behavior */
!
DBLINK_INIT;
initStringInfo(buf);
--- 443,457
dblink_close(PG_FUNCTION_ARGS)
{
PGconn *conn = NULL;
char *curname = NULL;
char *conname = NULL;
StringInfoData buf;
char *msg;
remoteConn *rconn = NULL;
bool fail = true; /* default to backward compatible behavior */
! ERRORCONTEXTCALLBACK;
!
! PUSH_DBERRCONTEXT(dblink_error_callback);
DBLINK_INIT;
initStringInfo(buf);
***
*** 471,481
Re: [HACKERS] CommitFest 2009-09, two weeks on
On Thu, Oct 01, 2009 at 09:05:55PM +0200, Boszormenyi Zoltan wrote: Yes, but technical problems and solutions do. ECPG claims to be ESQL/C compatible, but at places it's only half compatible. Where does it claim to be fully compatible? This comment is misleading and reflects quite a narrow POV. Not only OPEN and DECLARE may be out of scope, but FETCH and CLOSE as well. The reason why ESQL/C allows this construct is that this ultimately allows using embedded SQL in event-driven code in a straightforward way. For this purpose, native ECPG code is not usable currently, or you need programming tricks, like tracking whether the cursor is open and protecting DECLARE and OPEN under some conditional branch to avoid double open, etc. A straight DECLARE, OPEN, FETCH(s) and CLOSE series in the same function is only good for batch programming. Examples? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use 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] CommitFest 2009-09, two weeks on
Michael Meskes írta:
On Thu, Oct 01, 2009 at 09:05:55PM +0200, Boszormenyi Zoltan wrote:
Yes, but technical problems and solutions do. ECPG claims
to be ESQL/C compatible, but at places it's only half compatible.
Where does it claim to be fully compatible?
I didn't say it claims to be fully compatible, but it's
a hint that ecpg -C INFORMIX[_SE] exists. :-)
This comment is misleading and reflects quite a narrow POV.
Not only OPEN and DECLARE may be out of scope,
but FETCH and CLOSE as well. The reason why ESQL/C
allows this construct is that this ultimately allows using
embedded SQL in event-driven code in a straightforward way.
For this purpose, native ECPG code is not usable currently,
or you need programming tricks, like tracking whether the
cursor is open and protecting DECLARE and OPEN under
some conditional branch to avoid double open, etc. A straight
DECLARE, OPEN, FETCH(s) and CLOSE series in
the same function is only good for batch programming.
Examples?
I took my outofscope.pgc example from our out of
scope patch and shortened it. Compare the ecpg-native and
compat outputs and the esql output of the same file. The ecpg
outputs are generated with 8.4.1 plus out patches added, the
native output differs only from 8.3.7's ecpg in the amount of
whitespaces emitted between literals. The get_record1()
function can be called from a button-handler, e.g. when pressing
PgDn, or similar... No tricks needed, straightforward code.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
#include stdio.h
#include stdlib.h
#include string.h
#include inttypes.h
exec sql begin declare section;
exec sql include struct.h;
exec sql end declare section;
exec sql whenever sqlerror stop;
static void
get_var1(MYTYPE **myvar0, MYNULLTYPE **mynullvar0)
{
exec sql begin declare section;
MYTYPE *myvar = malloc(sizeof(MYTYPE));
MYNULLTYPE *mynullvar = malloc(sizeof(MYNULLTYPE));
exec sql end declare section;
/* Test DECLARE ... SELECT ... INTO with pointers */
exec sql declare mycur cursor for select * INTO :myvar :mynullvar from
a1;
if (sqlca.sqlcode != 0)
exit(1);
*myvar0 = myvar;
*mynullvar0 = mynullvar;
}
static void
open_cur1(void)
{
exec sql open mycur;
if (sqlca.sqlcode != 0)
exit(1);
}
static void
get_record1(void)
{
exec sql fetch mycur;
if (sqlca.sqlcode != 0 sqlca.sqlcode != SQLNOTFOUND)
exit(1);
}
static void
close_cur1(void)
{
exec sql close mycur;
if (sqlca.sqlcode != 0)
exit(1);
}
int
main (void)
{
MYTYPE *myvar;
MYNULLTYPE *mynullvar;
char msg[128];
ECPGdebug(1, stderr);
exec sql connect to test;
exec sql create table a1(id serial primary key, t text, d1 numeric, d2
float8, c character(10));
exec sql insert into a1(id, t, d1, d2, c) values (default, 'a', 1.0, 2,
'a');
exec sql insert into a1(id, t, d1, d2, c) values (default, null, null,
null, null);
exec sql insert into a1(id, t, d1, d2, c) values (default, 'a', -1.0,
'nan'::float8, 'a');
exec sql insert into a1(id, t, d1, d2, c) values (default, 'b', 2.0, 3,
'b');
exec sql commit;
/* Test out-of-scope DECLARE/OPEN/FETCH/CLOSE */
get_var1(myvar, mynullvar);
open_cur1();
while (1)
{
memset(myvar, 0, sizeof(MYTYPE));
get_record1();
if (sqlca.sqlcode == SQLNOTFOUND)
break;
printf(id=%d%s t='%s'%s d1=%lf%s d2=%lf%s c = '%s'%s\n,
myvar-id, mynullvar-id ? (NULL) : ,
myvar-t, mynullvar-t ? (NULL) : ,
myvar-d1, mynullvar-d1 ? (NULL) : ,
myvar-d2, mynullvar-d2 ? (NULL) : ,
myvar-c, mynullvar-c ? (NULL) : );
}
close_cur1();
exec sql drop table a1;
exec sql commit;
exec sql disconnect all;
return (0);
}
struct mytype {
int id;
char t[64];
double d1; /* dec_t */
double d2;
char c[30];
};
typedef struct mytype MYTYPE;
struct mynulltype {
int id;
int t;
int d1;
int d2;
int c;
};
typedef struct mynulltype MYNULLTYPE;
/* Processed by ecpg (4.5.0) */
/* These include files are added by the preprocessor */
#include ecpglib.h
#include ecpgerrno.h
#include sqlca.h
/* End of automatic include section */
#line 1 outofscope.ec
#include stdio.h
#include
Re: [HACKERS] CommitFest 2009-09, two weeks on
On Fri, Oct 2, 2009 at 9:01 PM, Boszormenyi Zoltan z...@cybertec.at wrote:
Hi,
Michael Meskes írta:
It is accepted either way. I was just pointing out that it might be easier to
review/commit at least parts of your patches if they can be applied
seperately.
I have split up (and cleaned up a little) the dynamic
cursorname patch into smaller logical, easier-to-review
pieces. Descriptions below.
1) 1a-unified-optfromin-fetch-ctxdiff.patch
ecpg supports optional FROM/IN in FETCH and
MOVE statements (mainly because it's required by
Informix-compatibility). Unify core and ecpg grammar
as per Tom Lane's suggestion.
2) 1b-cursor_name-ctxdiff.patch
name - cursor_name transition in core grammar
and ecpg grammar. Currently it does nothing, it's a
preparation phase. Depends on patch 1.
3) 1c-remove-var-from-list.patch
Introduce function remove_variable_from_list().
It is used by the dynamic cursor, SQLDA and DESCRIBE
patches for different reasons. Applicable separately.
4) 1d-dynamiccur-ctxdiff.patch
The real point of the whole series in this email.
Extend cursor_name in the ecpg grammar to actually
accept a character variable. The cursorname-as-variable
is replaced in the final SQL script with a $0 placeholder.
Doesn't compile as-is, requires patch 5 to get the
two shift/reduce conflicts fixed. Depends on patches
1, 2 and 3.
5) 1e-fix-shiftreduce-ctxdiff.patch
De-factorize BACKWARD opt_from_in cursor_name
and FORWARD opt_from_in cursor_name out of
fetch_args and pull them up into FetchStmt in the ecpg
grammar. Depends on patch 4.
One line in parse.pl is not clear for me:
$replace_line{'fetch_args'} = 'ignore';
The genarated preproc.y is the same with or without
this line. But as the previous version had it with
fetch_direction, I left it in.
6) 1f-cursorname-in-varchar-ctxdiff.patch
Allow that varchar can be used as cursorname as well.
Other character variable types were already supported.
Depends on patch 4.
7) 1g-regressiontests-ctxdiff.patch
Introduce cursor.pgc regression test for both native
and compat mode. Depends on all patches.
8) 1h-fix-parse.pl-ctxdiff.patch
Now useless patch, in the previous dynamic cursorname
patch the following scenario occured: the same rule
had both an addon and a rule extension. Without
this fix, the following code was generated in preproc.y:
ruleA: accepted syntax
{
addon code block
{
automatic code block
}
With the cleanup I did during this splitup, this scenario
doesn't happen, but this fix may be considered useful.
Applicable separately.
After every patch (except 4) both the core and ecpg
make check are successful.
It would've been nice if you'd changed the subject line before posting these.
Also, please update commitfest.postgresql.org appropriately.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ECPG dynamic cursorname patch revised and split Re: [HACKERS] CommitFest 2009-09, two weeks on
Robert Haas írta: On Fri, Oct 2, 2009 at 9:01 PM, Boszormenyi Zoltan z...@cybertec.at wrote: Hi, Michael Meskes írta: It is accepted either way. I was just pointing out that it might be easier to review/commit at least parts of your patches if they can be applied seperately. I have split up (and cleaned up a little) the dynamic cursorname patch into smaller logical, easier-to-review pieces. Descriptions below. ... After every patch (except 4) both the core and ecpg make check are successful. It would've been nice if you'd changed the subject line before posting these. At 3am, I forgot this. :( I hope the archive threading doesn't break and my previous mail will be referenced by this one. Also, please update commitfest.postgresql.org appropriately. I just did, thanks for the reminder. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- 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] CommitFest 2009-09, two weeks on
On Thu, Oct 1, 2009 at 04:11, Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp wrote: Magnus Hagander mag...@hagander.net wrote: I can certainly review the win32 encoding patch, but I was rather hoping for some comments from others on if we're interested in a win32 only solution, or if we want something more generic. Should we just go with the win32-only one for now? Yes, because Windows is only platform that supports UTF-16 encoding natively. I believe my patch is the best solution for Windows even if we have another approach for other platforms. Actually, I think a better argument is that since Windows will *never* accept UTF8 logging, and that's what most databases will be in, much of this patch will be required anyway. So I should probably review and get this part in while we think about other solutions *as well* for other platforms. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] CommitFest 2009-09, two weeks on
On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote: qualified to review them. (I don't actually think we have anybody except Michael who's really familiar with ecpg.) I'm afraid I'm simply not able to spend much time on this in the near future as I'm simply too busy atm. I spend some time on these the last time, but wasn't even able to see how Zoltan changed the points we mentioned back then, but I'm sure he has. As already noted the patches stack on each other. There doesn't seem to be a technical reason for this at least not for some of those dependencies. With the first patch changing the grammar file and thus taking quite some reviewing effort this slows things down even more because one needs more effort to review for instance the sqlda addition, although that one seems to be quite easy to review. All of this is written from the top of my head, so please bear with me if I missed any changes in the patches. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use 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] CommitFest 2009-09, two weeks on
Michael Meskes írta: On Wed, Sep 30, 2009 at 12:34:23PM -0400, Tom Lane wrote: qualified to review them. (I don't actually think we have anybody except Michael who's really familiar with ecpg.) I'm afraid I'm simply not able to spend much time on this in the near future as I'm simply too busy atm. I spend some time on these the last time, but wasn't even able to see how Zoltan changed the points we mentioned back then, but I'm sure he has. As already noted the patches stack on each other. There doesn't seem to be a technical reason for this at least not for some of those dependencies. With the first patch changing the grammar file and thus taking quite some reviewing effort this slows things down even more because one needs more effort to review for instance the sqlda addition, although that one seems to be quite easy to review. You're not being fair with me. The dependencies are quite technical. First, Tom Lane suggested to unify core and ecpg FETCH syntaxes so both will accept optional FROM/IN, which I did. SQLDA support adds new FETCH forms (Informix-specific ones) so naturally these patches clash. There's no simple way to make they separately applicable. With the first version, the same technical dependency were also there, because of the (already explained) grammar problem, I got 2 shift/reduce problems in the FETCH/MOVE stmts unless I de-factorized FORWARD and BACKWARD out of fetch_direction. The new FETCH forms with SQLDA touched the same areas in ecpg.addon. Second, DESCRIBE support and SQLDA support also overlap, because SQLDA is a new descriptor form, and DESCRIBE has to support both SQL descriptors and SQLDA. Well, I can split the DESCRIBE patch in half, so it will be usable on SQL descriptors but the other part would depend on both SQLDA and basic DESCRIBE support. Technical dependency again. What non-technical dependencies are you talking about? Please explain, so I may fix them. Saying it vaguely doesn't help. When I first posted the split patchset, you didn't tell me that the split is no good. I tried everything help I could to explain why I did what. Also, the current reviewer (Dan Colish) haven't contacted me despite I offered help privately. I can't review my own patches, that's clear. But I can't do anything else to speed review up but to offer my help and wait for the help/explanation request that didn't arrive. Also, I have sent some independent very small patches, that don't even need much review. One of them (the typo in pgc.l) was already applied and I thank you Michael, but the memory leak fix for two improperly freed numerics is still behind. Please, look at that patch, it should be really obvious. All of this is written from the top of my head, so please bear with me if I missed any changes in the patches. Michael Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- 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] CommitFest 2009-09, two weeks on
Boszormenyi Zoltan escribió: First, Tom Lane suggested to unify core and ecpg FETCH syntaxes so both will accept optional FROM/IN, which I did. SQLDA support adds new FETCH forms (Informix-specific ones) so naturally these patches clash. There's no simple way to make they separately applicable. With the first version, the same technical dependency were also there, because of the (already explained) grammar problem, I got 2 shift/reduce problems in the FETCH/MOVE stmts unless I de-factorized FORWARD and BACKWARD out of fetch_direction. The new FETCH forms with SQLDA touched the same areas in ecpg.addon. Probably the parts that touch the core grammar can be reviewed and applied separately. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] CommitFest 2009-09, two weeks on
On Thu, Oct 01, 2009 at 03:47:07PM +0200, Boszormenyi Zoltan wrote: You're not being fair with me. The dependencies are quite technical. I'm sorry that you interpreted my email this way, it wasn't at all meant to offend you. First, Tom Lane suggested to unify core and ecpg FETCH syntaxes so both will accept optional FROM/IN, which I did. SQLDA support adds new FETCH forms (Informix-specific This is actually one I was talking about. Adding SQLDA *only* seems like an easy one, as soon as it also hits the parser it becomes more complicated. This is not to say that it is not doable, but it wasn't for me with my time constraints. I was just explaining why I didn't delve into these any more so far. When I first posted the split patchset, you didn't tell me that the split is no good. I tried everything help I could to explain why I did what. Well actually I did, but that's not the problem here. I have no idea why you are ranting like this just because of me excusing myself for a lack of time. Also, the current reviewer (Dan Colish) haven't contacted me despite I offered help privately. I can't review my own patches, that's clear. But I can't do anything else to speed review up but to offer my help and wait for the help/explanation request that didn't arrive. Okay, so it's all my fault. Do you feel better now? Also, I have sent some independent very small patches, that don't even need much review. One of them (the typo in pgc.l) was already applied and I thank you Michael, but the memory leak fix for two improperly freed numerics is still behind. Please, look at that patch, it should be really obvious. My last commit was one of your patches, obviously I didn't do anything on ecpg since. I'm not sure what you are trying to tell me, you might want to explain the last two sentences. But keep in mind you are *not* the one to decide how I spend my spare time. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use 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] CommitFest 2009-09, two weeks on
Michael Meskes írta: On Thu, Oct 01, 2009 at 03:47:07PM +0200, Boszormenyi Zoltan wrote: You're not being fair with me. The dependencies are quite technical. I'm sorry that you interpreted my email this way, it wasn't at all meant to offend you. Please, accept my apologies, I only tried to express my frustration, this is not a good situation for either of us. You were busy with your job and other occupations. We have a serious project going on that depend on ECPG being more compatible to Informix. First, Tom Lane suggested to unify core and ecpg FETCH syntaxes so both will accept optional FROM/IN, which I did. SQLDA support adds new FETCH forms (Informix-specific This is actually one I was talking about. Adding SQLDA *only* seems like an easy one, as soon as it also hits the parser it becomes more complicated. This is not to say that it is not doable, but it wasn't for me with my time constraints. I was just explaining why I didn't delve into these any more so far. This is now clear, I will separate that part out and post it. But this means that the same core grammar parts will be touched twice because two basic things are done there: - optional FROM/IN in core grammar, ECPG grammar updated - name - cursor_name transition in cursor-related statements in the core grammar and the dynamic cursorname patch So, technically dependant patches again, but maybe easier on the reviewer. Would this be accepted this way? Or the two modification washed into one? When I first posted the split patchset, you didn't tell me that the split is no good. I tried everything help I could to explain why I did what. Well actually I did, but that's not the problem here. I have no idea why you are ranting like this just because of me excusing myself for a lack of time. I am very sorry, under stress sometimes I get like a steam engine overloaded. Not a good behaviour at 37, I know. I am very sorry. Also, the current reviewer (Dan Colish) haven't contacted me despite I offered help privately. I can't review my own patches, that's clear. But I can't do anything else to speed review up but to offer my help and wait for the help/explanation request that didn't arrive. Okay, so it's all my fault. Do you feel better now? It's not your fault at all, it's a difficult situation and I had to express it somehow. My tone was not proper. BTW, thanks for adding my small collected knowledge about the ECPG grammar as official documentation. Also, I have sent some independent very small patches, that don't even need much review. One of them (the typo in pgc.l) was already applied and I thank you Michael, but the memory leak fix for two improperly freed numerics is still behind. Please, look at that patch, it should be really obvious. My last commit was one of your patches, Yes, the pgc.l one-liner. Thanks again for committing that. obviously I didn't do anything on ecpg since. I'm not sure what you are trying to tell me, you might want to explain the last two sentences. I thought you forgot that patch, the please, look at that patch was an (I thought) polite request, it's really two one-liners. But keep in mind you are *not* the one to decide how I spend my spare time. Obviously. Please, accept my apologies. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- 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] CommitFest 2009-09, two weeks on
On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote: Please, accept my apologies, I only tried to express my frustration, this is not a good situation for either of us. Apologies accepted, email is a difficult means of communication anyway. It leads to misunderstanding IMO. You were busy with your job and other occupations. We have a serious project going on that depend on ECPG being more compatible to Informix. Please keep in mind that the needs of your business project cannot and will not influence the way PostgreSQL as on OSS project will work. Would this be accepted this way? Or the two modification washed into one? It is accepted either way. I was just pointing out that it might be easier to review/commit at least parts of your patches if they can be applied seperately. I thought you forgot that patch, the please, look at that patch was an (I thought) polite request, it's really two one-liners. Well, this is true as the patch was buried in the long thread containing all the other ones. And yes, now that you brought it into my memory again, I already committed it. Sorry for missing it. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo/Skype: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use 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] CommitFest 2009-09, two weeks on
Michael Meskes írta:
On Thu, Oct 01, 2009 at 07:21:54PM +0200, Boszormenyi Zoltan wrote:
Please, accept my apologies, I only tried to express my
frustration, this is not a good situation for either of us.
Apologies accepted, email is a difficult means of communication anyway. It
leads to misunderstanding IMO.
You were busy with your job and other occupations.
We have a serious project going on that depend on
ECPG being more compatible to Informix.
Please keep in mind that the needs of your business project cannot and will
not
influence the way PostgreSQL as on OSS project will work.
Yes, but technical problems and solutions do. ECPG claims
to be ESQL/C compatible, but at places it's only half compatible.
For our project to succeed, we need more compatibility in ECPG.
It's easier to solve these problems in ECPG than to code around it
in literally thousands of little programs.
BTW, a thought about the comment in ecpg.header about adjust_informix():
/* Informix accepts DECLARE with variables that are out of scope
when OPEN is called.
* for instance you can declare variables in a function, and
then subsequently use them
* {
* declare_vars();
* exec sql ... which uses vars declared in the above function
*
* This breaks standard and leads to some very dangerous
programming.
This comment is misleading and reflects quite a narrow POV.
Not only OPEN and DECLARE may be out of scope,
but FETCH and CLOSE as well. The reason why ESQL/C
allows this construct is that this ultimately allows using
embedded SQL in event-driven code in a straightforward way.
For this purpose, native ECPG code is not usable currently,
or you need programming tricks, like tracking whether the
cursor is open and protecting DECLARE and OPEN under
some conditional branch to avoid double open, etc. A straight
DECLARE, OPEN, FETCH(s) and CLOSE series in
the same function is only good for batch programming.
Would this be accepted this way? Or the two modification washed into one?
It is accepted either way. I was just pointing out that it might be easier to
review/commit at least parts of your patches if they can be applied
seperately.
Okay, I will split the remaining patches into more little pieces
that can reviewed more easily. Some patches will still build
on earlier ones in the series, that's unavoidable.
I thought you forgot that patch, the please, look at that patch
was an (I thought) polite request, it's really two one-liners.
Well, this is true as the patch was buried in the long thread containing all
the other ones. And yes, now that you brought it into my memory again, I
already committed it. Sorry for missing it.
Thank you very much for committing it.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
--
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] CommitFest 2009-09, two weeks on
Robert Haas wrote: - Hot Standby and Streaming Replication are both huge new features in this CommitFest, and there seems to be a fair amount of activity around both patches. Heikki previously expressed optimism about getting Hot Standby done this CommitFest, but I am not sure whether he is still feeling optimistic, There's a lot of small things that need fixing, but nothing major. I'm not so much optimistic, but I think we should spend the extra effort required on hot standby to force it in in this commitfest. It's a big feature and it really could use some alpha-testing earlier rather than later. It would also leave time for any extra features or tweaks to be made in the later commitfests. OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it should be returned to author at this point, I should move on to other patches to get the commitfest closed ASAP, and continue reviewing and polishing that right after the commitfest. or what his feelings are about Streaming Replication, which is currently waiting on Fujii Masao for a new version. I'm undecided on whether walreceiver should be a subprocess of the startup process, or of postmaster as it was submitted. I'd appreciate if others would take a look into that too and give opinions. And then there's the small list of things I asked Fujii-san to work on. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] CommitFest 2009-09, two weeks on
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it should be returned to author at this point, I should move on to other patches to get the commitfest closed ASAP, and continue reviewing and polishing that right after the commitfest. FWIW, I'd rather you kept focusing on those two patches while other committers work on the rest. From what I've seen you're finding a whole lot of broken or at least questionable stuff, and even if they're individually minor issues, that adds up to a lot of instability. I agree that these patches need special attention and should not be treated exactly the same as we'd treat smaller patches. regards, tom lane -- 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] CommitFest 2009-09, two weeks on
On Wed, Sep 30, 2009 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it should be returned to author at this point, I should move on to other patches to get the commitfest closed ASAP, and continue reviewing and polishing that right after the commitfest. FWIW, I'd rather you kept focusing on those two patches while other committers work on the rest. From what I've seen you're finding a whole lot of broken or at least questionable stuff, and even if they're individually minor issues, that adds up to a lot of instability. I agree that these patches need special attention and should not be treated exactly the same as we'd treat smaller patches. I tend to agree. I think it's reasonable for you (meaning Heikki) to devote far more time and effort to those patches than you would to other patches implementing more run-of-the-mill features, and it seems like there is no shortage of things to find and fix. I don't think that having you take a break to work on other patches is going to be to the overall benefit of the project (and many of the more significant remaining patches look like they are right up Tom's alley anyway). That having been said, if Hot Standby is still closer to commit than Streaming Replication, it might make sense to push Streaming Replication off until November, or at least post-CommitFest. Do you have any sense of how soon you'll feel confident to commit either patch? ...Robert -- 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] CommitFest 2009-09, two weeks on
Robert Haas wrote: - There is one dblink pach left over from last CommitFest. Joe Conway was going to review it the weekend of July 18th-19th, but that didn't end up happening and so that patch is still waiting. We might be able to find someone else to review it, but I'm not sure whether that will help unless there is a committer other than Joe with bandwidth to do the final review and commit. I will get to it before the end of this commitfest, but I have to admit I'm not all that excited about this patch in the first place. I don't know that I agree with the need. Joe signature.asc Description: OpenPGP digital signature
Re: [HACKERS] CommitFest 2009-09, two weeks on
Robert Haas wrote: On Wed, Sep 30, 2009 at 11:36 AM, Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it should be returned to author at this point, I should move on to other patches to get the commitfest closed ASAP, and continue reviewing and polishing that right after the commitfest. FWIW, I'd rather you kept focusing on those two patches while other committers work on the rest. From what I've seen you're finding a whole lot of broken or at least questionable stuff, and even if they're individually minor issues, that adds up to a lot of instability. I agree that these patches need special attention and should not be treated exactly the same as we'd treat smaller patches. I tend to agree. I think it's reasonable for you (meaning Heikki) to devote far more time and effort to those patches than you would to other patches implementing more run-of-the-mill features, and it seems like there is no shortage of things to find and fix. I don't think that having you take a break to work on other patches is going to be to the overall benefit of the project (and many of the more significant remaining patches look like they are right up Tom's alley anyway). Ok, good, I'm more than happy to continue fine-combing hot standby. That having been said, if Hot Standby is still closer to commit than Streaming Replication, it might make sense to push Streaming Replication off until November, or at least post-CommitFest. Commitfest or no-commitfest, I'm planning to continue working on the streaming replication patch in any case until it's committed. Do you have any sense of how soon you'll feel confident to commit either patch? I'm bad at estimating. Not this week for sure, and next week I'm traveling and won't be able to spend as much time on it as I am right now. If no new major issues are found, and all the outstanding issues are resolved by me or Simon by then, maybe the week after that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] CommitFest 2009-09, two weeks on
Joe Conway m...@joeconway.com writes: Robert Haas wrote: - There is one dblink pach left over from last CommitFest. Joe Conway was going to review it the weekend of July 18th-19th, but that didn't end up happening and so that patch is still waiting. We might be able to find someone else to review it, but I'm not sure whether that will help unless there is a committer other than Joe with bandwidth to do the final review and commit. I will get to it before the end of this commitfest, but I have to admit I'm not all that excited about this patch in the first place. I don't know that I agree with the need. Well, you're the dblink expert. If you think it should be rejected I doubt many of us will argue with you. regards, tom lane -- 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] CommitFest 2009-09, two weeks on
Robert Haas robertmh...@gmail.com writes: ... (and many of the more significant remaining patches look like they are right up Tom's alley anyway). FWIW, if left to my own devices I will eventually get to everything except the dblink, ecpg, and encoding/win32 patches. I don't intend to touch any of those because there are other committers better qualified to review them. (I don't actually think we have anybody except Michael who's really familiar with ecpg.) However, if no other committers are working on it it's going to be a long commitfest ... The other problem is that most of the patches are not Ready for Committer anyway. regards, tom lane -- 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] CommitFest 2009-09, two weeks on
On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Joe Conway m...@joeconway.com writes: Robert Haas wrote: - There is one dblink pach left over from last CommitFest. Joe Conway was going to review it the weekend of July 18th-19th, but that didn't end up happening and so that patch is still waiting. We might be able to find someone else to review it, but I'm not sure whether that will help unless there is a committer other than Joe with bandwidth to do the final review and commit. I will get to it before the end of this commitfest, but I have to admit I'm not all that excited about this patch in the first place. I don't know that I agree with the need. Well, you're the dblink expert. If you think it should be rejected I doubt many of us will argue with you. Yep. CommitFest doesn't mean commit it; it means decide whether to commit it. Things being rejected or returned with feedback for further improvement is fine; we're just trying to avoid long periods with no response at all. ...Robert -- 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] CommitFest 2009-09, two weeks on
On Wed, Sep 30, 2009 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: ... (and many of the more significant remaining patches look like they are right up Tom's alley anyway). FWIW, if left to my own devices I will eventually get to everything except the dblink, ecpg, and encoding/win32 patches. I don't intend to touch any of those because there are other committers better qualified to review them. (I don't actually think we have anybody except Michael who's really familiar with ecpg.) Thanks, I think that's helpful information. However, if no other committers are working on it it's going to be a long commitfest ... That is my concern as well. The other problem is that most of the patches are not Ready for Committer anyway. I (and hopefully the people who agreed to help with patch-chasing) can work on this, but given that there are 5 that are Ready for Committer and probably as many more that are close, and further given that in the past 7 days exactly 1 patch from the CommitFest has been committed, I'm not sure there's a real problem here. If you commit/bounce all 5 of those afternoon I will spend the evening making sure you have a few more to tackle tomorrow. ...Robert -- 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] CommitFest 2009-09, two weeks on
Robert Haas wrote: On Wed, Sep 30, 2009 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: ... (and many of the more significant remaining patches look like they are right up Tom's alley anyway). FWIW, if left to my own devices I will eventually get to everything except the dblink, ecpg, and encoding/win32 patches. I don't intend to touch any of those because there are other committers better qualified to review them. (I don't actually think we have anybody except Michael who's really familiar with ecpg.) Thanks, I think that's helpful information. However, if no other committers are working on it it's going to be a long commitfest ... That is my concern as well. I have been (and still am somewhat) slammed, but I can probably make space to work on Encoding issues in console and eventlog on win32 https://commitfest.postgresql.org/action/patch_view?id=148 some time in the next day or three. After that, if I still have time and nobody else has grabbed it, I'll move on to CREATE LIKE INCLUDING COMMENTS and STORAGE https://commitfest.postgresql.org/action/patch_view?id=172. cheers andrew -- 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] CommitFest 2009-09, two weeks on
Robert Haas wrote: On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Joe Conway m...@joeconway.com writes: Robert Haas wrote: - There is one dblink pach left over from last CommitFest. Joe Conway was going to review it the weekend of July 18th-19th, but that didn't end up happening and so that patch is still waiting. We might be able to find someone else to review it, but I'm not sure whether that will help unless there is a committer other than Joe with bandwidth to do the final review and commit. I will get to it before the end of this commitfest, but I have to admit I'm not all that excited about this patch in the first place. I don't know that I agree with the need. Well, you're the dblink expert. If you think it should be rejected I doubt many of us will argue with you. Yep. CommitFest doesn't mean commit it; it means decide whether to commit it. Things being rejected or returned with feedback for further improvement is fine; we're just trying to avoid long periods with no response at all. The issue is not so much technical as it is philosophical. The patch basically forces all use of libpq by dblink to be asynchronous (internally) so that a cancel can be sensed and passed down to the remote side and everything cleaned up. Possibly the right thing to do, but dblink already allows the use of async queries, and the current synchronous method uses standard libpq calls. If all of this is really necessary, doesn't every libpq client have the same issue? If so why have the synchronous libpq functions at all? So while I can vet the patch technically, and spend more time understanding the use case, and maybe explaining it better, I think other people should weigh in on the change as it is significant and points to other potential issues. Joe signature.asc Description: OpenPGP digital signature
Re: [HACKERS] CommitFest 2009-09, two weeks on
On Wed, Sep 30, 2009 at 18:34, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: ... (and many of the more significant remaining patches look like they are right up Tom's alley anyway). FWIW, if left to my own devices I will eventually get to everything except the dblink, ecpg, and encoding/win32 patches. I don't intend to touch any of those because there are other committers better qualified to review them. (I don't actually think we have anybody except Michael who's really familiar with ecpg.) I can certainly review the win32 encoding patch, but I was rather hoping for some comments from others on if we're interested in a win32 only solution, or if we want something more generic. Should we just go with the win32-only one for now? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] CommitFest 2009-09, two weeks on
Magnus Hagander escribió: On Wed, Sep 30, 2009 at 18:34, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: ... (and many of the more significant remaining patches look like they are right up Tom's alley anyway). FWIW, if left to my own devices I will eventually get to everything except the dblink, ecpg, and encoding/win32 patches. I don't intend to touch any of those because there are other committers better qualified to review them. (I don't actually think we have anybody except Michael who's really familiar with ecpg.) I can certainly review the win32 encoding patch, but I was rather hoping for some comments from others on if we're interested in a win32 only solution, or if we want something more generic. Should we just go with the win32-only one for now? Just a couple of days ago a question came on the spanish list because someone was getting mixed UTF8 and Latin1 output in a log file. This was in Fedora IIRC, so maybe we do want something more general. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] CommitFest 2009-09, two weeks on
Magnus Hagander mag...@hagander.net writes: I can certainly review the win32 encoding patch, but I was rather hoping for some comments from others on if we're interested in a win32 only solution, or if we want something more generic. Should we just go with the win32-only one for now? That was actually the only substantive comment I had about it. I don't see why it's a win32-only problem or why a win32-only solution is a good approach. regards, tom lane -- 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] CommitFest 2009-09, two weeks on
On Wed, Sep 30, 2009 at 21:38, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: I can certainly review the win32 encoding patch, but I was rather hoping for some comments from others on if we're interested in a win32 only solution, or if we want something more generic. Should we just go with the win32-only one for now? That was actually the only substantive comment I had about it. I don't see why it's a win32-only problem or why a win32-only solution is a good approach. Yeah, that's my thought as well. If we want a complete one, we should reject this patch and ask for one that does that. If we are fine with a win32 only one, I can review this one and get it in. I'm leaning towards us wanting a general one, but I'm unsure how much work that will take. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- 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] CommitFest 2009-09, two weeks on
Joe Conway m...@joeconway.com writes: The issue is not so much technical as it is philosophical. The patch basically forces all use of libpq by dblink to be asynchronous (internally) so that a cancel can be sensed and passed down to the remote side and everything cleaned up. Possibly the right thing to do, but dblink already allows the use of async queries, and the current synchronous method uses standard libpq calls. If all of this is really necessary, doesn't every libpq client have the same issue? Well, only the ones that want to implement cancel and don't have access to the app's own signal handling functions. (Which suggests that a possible answer is to allow dblink to hook into the SIGINT catcher, but frankly hooks in that location scare me ...) I would argue that it's not necessarily a good idea at all: one of the typical uses for dblink is to fake autonomous transactions, and in that application I don't think you *want* a cancel to propagate to the other session. If we did put this behavior into all dblink operations, we'd need a way to turn it off. Since dblink_cancel_query is already available, people who do want cancels to propagate have the ability to do that. I'm inclined to think that this is complexity we don't need. regards, tom lane -- 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] CommitFest 2009-09, two weeks on
Joe Conway m...@joeconway.com wrote: The patch basically forces all use of libpq by dblink to be asynchronous (internally) so that a cancel can be sensed and passed down to the remote side and everything cleaned up. Possibly the right thing to do, but dblink already allows the use of async queries, and the current synchronous method uses standard libpq calls. The point is *memory leak* in dblink when a query is canceled or become time-out. I think it is a bug, and my patch could fix it. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- 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] CommitFest 2009-09, two weeks on
Magnus Hagander mag...@hagander.net wrote: I can certainly review the win32 encoding patch, but I was rather hoping for some comments from others on if we're interested in a win32 only solution, or if we want something more generic. Should we just go with the win32-only one for now? Yes, because Windows is only platform that supports UTF-16 encoding natively. I believe my patch is the best solution for Windows even if we have another approach for other platforms. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CommitFest 2009-09, two weeks on
It's now been two weeks since we started this CommitFest, so it seems like a good time to review where we are. Here are my thoughts, for what that's worth. Our overall rate of progress is significantly slower than it was last time around. At a similar point in the July CommitFest, 19 patches had been committed (not counting 3 that were committed before the start of the CommitFest), 11 had been returned with feedback (again, not counting 2 from before the start of the CommitFest), and 3 had been rejected. The corresponding numbers for this CommitFest are 8, 7, and 3, which means that the rate of returning patches with feedback and/or rejecting them is only modestly lower, but the rate of committing is much lower. I'm not sure whether this is because the patches are more complex, because the committers have been busy with other issues, or some other reason. We also have fewer patches than we did last time around. I believe we started the last CommitFest with a bit more than 75 patches (there are fewer now, as some were moved to this CommitFest) and we started this one with just 48. This somewhat balances out the slower rate of grinding through the patch queue, but I'm still a bit worried about the rate at which we're making progress. It would be nice to be done on time, and I'm not sure we're going to make it. With respect to individual patches: - There are three ECPG patches for which it's been difficult to find a reviewer. It seems we don't have any reviewers familiar with ECPG. If anyone is able to help review these, it would be much appreciated. - There is one dblink pach left over from last CommitFest. Joe Conway was going to review it the weekend of July 18th-19th, but that didn't end up happening and so that patch is still waiting. We might be able to find someone else to review it, but I'm not sure whether that will help unless there is a committer other than Joe with bandwidth to do the final review and commit. - Hot Standby and Streaming Replication are both huge new features in this CommitFest, and there seems to be a fair amount of activity around both patches. Heikki previously expressed optimism about getting Hot Standby done this CommitFest, but I am not sure whether he is still feeling optimistic, or what his feelings are about Streaming Replication, which is currently waiting on Fujii Masao for a new version. On the whole, it seems like patch authors have done a better job than last time of responding to feedback in a timely fashion - very little is falling out due to submitter inattention. That is good, although it also means that the percentage of patches that will require substantive action (rather than, say, summary rejection for non-communication) is apt to be higher. I am also generally under the impression that we have a larger number of complex patches this time around. Some of that may be because much good feedback was given in the last CommitFest, and previously half-baked ideas are coming back a little more well done. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
