Re: [PATCHES] msvc = VC7 understands __FUNCTION__
On Fri, Sep 28, 2007 at 10:43:17PM +0200, Hannes Eder wrote: Hi, Starting from version VC7 msvc supports __FUNCTION__, so I think this could be enabled in pg_config.h.win32, see attached diff. Applied, thanks. //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] OpenSSL Applink
On Sat, Sep 29, 2007 at 09:01:16PM +0100, Dave Page wrote: Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: From: Tom Lane [EMAIL PROTECTED] ... It's not entirely clear whether BIO_new_fp() would avoid the problematic calls, but it doesn't look like it'd be hard to try. The last version of the patch I posted uses BIO_new_file() in all cases, and (from memory) BIO_get_fp() in the non-win32 case to get a FILE* to pass to fstat. Did you manage to get rid of the bogus-error-message problem that afflicted the first version of the patch? If so, this way is fine. No, thats still an issue. A guess on this - probably the BIO stuff overwrites some internal OpenSSL errno value, causing the wrong error to be passed up. Most likely, it's not save to call BIO functions from inside the callback. My bet is that it'll actually break without this patch, if you stick something that's invalid in there. It's just taht we picked up the does not exist error without calling BIO functions. A quick peek at the OpenSSL sources seems to confirm this. I think we want to either attempt to load the client certificate before we connect (and before it's requested) and just queue up the error to show it in only if it's requested, or we want to try some magic around ERR_set_mark()/ERR_pop_to_mark() to clear out any BIO errors before we hand control back. I'll see if I can put together a poc patch - need to reproduce the problem first :-) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] 64bit compile linker problem of win32.mak.
Hi Magnus. I saw one problem on Platform SDK. http://support.microsoft.com/kb/894573/en/ This can be helped. Thanks! Regards, Hiroshi Saito win32mak_patch Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] TCL fix in HEAD
Bruce Momjian wrote: Marshall, Steve wrote: The recent TCL patch assumed Tcl_NotifierProcs.initNotifierProc was added in TCL 8.2: In fact it was added in 8.4 so I have modified the CVS with the following patch. I confirmed this against the 8.2.5 release. Sorry I did not notice that when I initially created the patch. While the patch will not work for the earlier releases, it should be noted that the multithhreading problem still exists when linking postgresql against TCL 8.2 and 8.3 libraries that are compiled with the preprocessor symbol TCL_THREADS defined. Unfortunately, we cannot override the initNotifier behavior in those releases, so we don't have a workable solution. This is probably not a big problem, since TCL was not commonly compiled with multithreading enabled prior to 8.4. However, perhaps there should be a warning in the documentation on PL/TCL directing users to avoid linking postgresql against TCL libraries earlier than 8.4 that have multithreading enabled? Can you send in a patch against pltcl.sgml? PL/TCL documentation patch is attached. *** pltcl.sgml 2007-10-01 08:29:06.667578247 -0400 --- pltcl.sgml.new 2007-10-01 08:24:41.736708719 -0400 *** *** 70,75 --- 70,87 literalcreatelang pltcl replaceabledbname//literal or literalcreatelang pltclu replaceabledbname//literal. /para +para + Care should be taken when linking the pltcl shared object code against + TCL libraries earlier than the TCL 8.4 release. The pre-8.4 versions of TCL must + be built emphasiswithout/emphasis multithreading support, i.e. with TCL_THREADS + undefined. Otherwise, the first use of PL/TCL functions will cause the postgres + backend to become multithreaded, resulting in subsequent unexpected state errors. + PL/TCL emphasiscan/emphasis be safely linked against multithreaded versions of the + TCL library for TCL versions 8.4 and later. In these cases, the pltcl source code uses + capabilities introduced in TCL 8.4 to override and disable the multithreading behavior. + Note that pre-8.4 versions of TCL were rarely built with multithreading support in + pre-compiled distributions, so this problem is rather rare. +/para /sect1 !-- PL/Tcl description -- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] OpenSSL Applink
On Mon, Oct 01, 2007 at 02:37:44PM +0200, Magnus Hagander wrote: On Sat, Sep 29, 2007 at 09:01:16PM +0100, Dave Page wrote: Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: From: Tom Lane [EMAIL PROTECTED] ... It's not entirely clear whether BIO_new_fp() would avoid the problematic calls, but it doesn't look like it'd be hard to try. The last version of the patch I posted uses BIO_new_file() in all cases, and (from memory) BIO_get_fp() in the non-win32 case to get a FILE* to pass to fstat. Did you manage to get rid of the bogus-error-message problem that afflicted the first version of the patch? If so, this way is fine. No, thats still an issue. A guess on this - probably the BIO stuff overwrites some internal OpenSSL errno value, causing the wrong error to be passed up. Most likely, it's not save to call BIO functions from inside the callback. My bet is that it'll actually break without this patch, if you stick something that's invalid in there. It's just taht we picked up the does not exist error without calling BIO functions. A quick peek at the OpenSSL sources seems to confirm this. I think we want to either attempt to load the client certificate before we connect (and before it's requested) and just queue up the error to show it in only if it's requested, or we want to try some magic around ERR_set_mark()/ERR_pop_to_mark() to clear out any BIO errors before we hand control back. I'll see if I can put together a poc patch - need to reproduce the problem first :-) Just a quick followup - this is also reproducible on Unix: [EMAIL PROTECTED]:~/inst-pg/head/bin$ PGSSLMODE=require ./psql -h localhost postgres psql: SSL SYSCALL error: Resource temporarily unavailable //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] OpenSSL Applink
On Mon, Oct 01, 2007 at 03:16:13PM +0200, Magnus Hagander wrote:
On Mon, Oct 01, 2007 at 02:37:44PM +0200, Magnus Hagander wrote:
On Sat, Sep 29, 2007 at 09:01:16PM +0100, Dave Page wrote:
Tom Lane wrote:
Dave Page [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
... It's not entirely clear whether BIO_new_fp() would avoid the
problematic calls, but it doesn't look like it'd be hard to try.
The last version of the patch I posted uses BIO_new_file() in all
cases, and (from memory) BIO_get_fp() in the non-win32 case to get a
FILE* to pass to fstat.
Did you manage to get rid of the bogus-error-message problem that
afflicted the first version of the patch? If so, this way is fine.
No, thats still an issue.
A guess on this - probably the BIO stuff overwrites some internal OpenSSL
errno value, causing the wrong error to be passed up. Most likely, it's
not save to call BIO functions from inside the callback. My bet is that
it'll actually break without this patch, if you stick something that's
invalid in there. It's just taht we picked up the does not exist error
without calling BIO functions.
A quick peek at the OpenSSL sources seems to confirm this.
I think we want to either attempt to load the client certificate before we
connect (and before it's requested) and just queue up the error to show it
in only if it's requested, or we want to try some magic around
ERR_set_mark()/ERR_pop_to_mark() to clear out any BIO errors before we hand
control back.
I'll see if I can put together a poc patch - need to reproduce the problem
first :-)
Yes, that was the problem. Attached patch fixes the problem for me on
Windows and Linux using the error mark functionality. It seems a lot
cleaner than the other option.
Dave - can you test this one? Assuming that works, I'll go ahead and apply
it.
I also think we have the same problem in the current code, just not for
fopen(). We trap fopen() without anything happening inside OpenSSL, but if
we get an error in the OpenSSL functions we call, something similar would
likely happen.
Should we backpatch all the stuff, or just the error push/pop thing?
//Magnus
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.94
diff -c -r1.94 fe-secure.c
*** src/interfaces/libpq/fe-secure.c16 Feb 2007 17:07:00 - 1.94
--- src/interfaces/libpq/fe-secure.c1 Oct 2007 13:21:43 -
***
*** 111,116
--- 111,117
#ifdef USE_SSL
#include openssl/ssl.h
+ #include openssl/bio.h
#if (SSLEAY_VERSION_NUMBER = 0x00907000L)
#include openssl/conf.h
#endif
***
*** 567,572
--- 568,577
*This callback is only called when the server wants a
*client cert.
*
+ *Since BIO functions can set OpenSSL error codes, we must
+ *reset the OpenSSL error stack on *every* exit from this
+ *function once we've started using BIO.
+ *
*Must return 1 on success, 0 on no data or error.
*/
static int
***
*** 579,586
struct stat buf2;
#endif
charfnbuf[MAXPGPATH];
! FILE *fp;
! PGconn *conn = (PGconn *) SSL_get_app_data(ssl);
charsebuf[256];
if (!pqGetHomeDirectory(homedir, sizeof(homedir)))
--- 584,592
struct stat buf2;
#endif
charfnbuf[MAXPGPATH];
! FILE*fp;
! BIO *bio;
! PGconn *conn = (PGconn *) SSL_get_app_data(ssl);
charsebuf[256];
if (!pqGetHomeDirectory(homedir, sizeof(homedir)))
***
*** 590,605
return 0;
}
/* read the user certificate */
snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_CERT_FILE);
! if ((fp = fopen(fnbuf, r)) == NULL)
{
printfPQExpBuffer(conn-errorMessage,
libpq_gettext(could not open certificate file
\%s\: %s\n),
fnbuf, pqStrerror(errno,
sebuf, sizeof(sebuf)));
return 0;
}
! if (PEM_read_X509(fp, x509, NULL, NULL) == NULL)
{
char *err = SSLerrmessage();
--- 596,616
return 0;
}
+ /* save OpenSSL error stack */
+ ERR_set_mark();
+
/* read the user certificate */
snprintf(fnbuf, sizeof(fnbuf), %s/%s, homedir, USER_CERT_FILE);
! if ((bio = BIO_new_file(fnbuf, r)) == NULL)
{
printfPQExpBuffer(conn-errorMessage,
libpq_gettext(could not open certificate file
\%s\: %s\n),
fnbuf, pqStrerror(errno,
sebuf, sizeof(sebuf)));
+
Re: [PATCHES] OpenSSL Applink
Magnus Hagander wrote: Yes, that was the problem. Attached patch fixes the problem for me on Windows and Linux using the error mark functionality. It seems a lot cleaner than the other option. Dave - can you test this one? Assuming that works, I'll go ahead and apply it. Yep, looks good here. Thanks. I also think we have the same problem in the current code, just not for fopen(). We trap fopen() without anything happening inside OpenSSL, but if we get an error in the OpenSSL functions we call, something similar would likely happen. Should we backpatch all the stuff, or just the error push/pop thing? All of it. Anyone building just libpq/psql using the old MSVC makefiles will probably see the applink problem if they try to use client certs. /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] 64bit compile linker problem of win32.mak.
On Mon, Oct 01, 2007 at 09:45:43PM +0900, Hiroshi Saito wrote: Hi Magnus. I saw one problem on Platform SDK. http://support.microsoft.com/kb/894573/en/ This can be helped. Thanks! Applied, thanks. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] OpenSSL Applink
Dave Page [EMAIL PROTECTED] writes: Magnus Hagander wrote: Should we backpatch all the stuff, or just the error push/pop thing? All of it. Anyone building just libpq/psql using the old MSVC makefiles will probably see the applink problem if they try to use client certs. I'd vote for backpatching, but only as far as 8.2, seeing that we're abandoning the older branches on Windows. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] OpenSSL Applink
On Mon, Oct 01, 2007 at 10:51:01AM -0400, Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: Magnus Hagander wrote: Should we backpatch all the stuff, or just the error push/pop thing? All of it. Anyone building just libpq/psql using the old MSVC makefiles will probably see the applink problem if they try to use client certs. I'd vote for backpatching, but only as far as 8.2, seeing that we're abandoning the older branches on Windows. Should we backpatch a version of it to previous versions that does just the error stack manipulation, or just ignore on the grounds that nobody has reported the problem there (it's there, but it's a lot more narrow - I know it's there, but I havent' been able to provoket it due to not knowing enough about setting up certificate chains and such) //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] OpenSSL Applink
Magnus Hagander [EMAIL PROTECTED] writes: On Mon, Oct 01, 2007 at 10:51:01AM -0400, Tom Lane wrote: I'd vote for backpatching, but only as far as 8.2, seeing that we're abandoning the older branches on Windows. Should we backpatch a version of it to previous versions that does just the error stack manipulation, or just ignore on the grounds that nobody has reported the problem there (it's there, but it's a lot more narrow - I know it's there, but I havent' been able to provoket it due to not knowing enough about setting up certificate chains and such) That's only a cosmetic problem (wrong error message), right? I'd vote for no backpatch, at least for now --- I'd rather see this change get through beta testing first. Anytime you're fooling with interactions with some other package, the risk of portability issues is high. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] Patch to inline stable SQL set returning UDFs
I discussed this hack with Neil and Josh in Ottawa back in May. I
took a stab at it a few weeks ago and below are the results. It is
mostly modeled after the existing inline_function. The approach taken
is to recursively cleanup the RTable where stable SQL functions are
found in it.
I've been testing this in our dev environment for a few weeks now.
I'm sure it still has issues but I think it is about as clean as I can
get it without help from a wider audience. This is my first backend
patch so please be gentle.
I want to thank Neil for answering many of my supremely ignorant
questions on IRC.
--
An eye for eye only ends up making the whole world blind. -- Mohandas Gandhi
diff -r -c3 postgres-8.3/src/backend/optimizer/plan/planner.c postgres-8.3-hacked/src/backend/optimizer/plan/planner.c
*** postgres-8.3/src/backend/optimizer/plan/planner.c 2007-05-26 14:23:01.0 -0400
--- postgres-8.3-hacked/src/backend/optimizer/plan/planner.c 2007-10-01 11:49:08.0 -0400
***
*** 256,261
--- 256,268
parse-jointree-quals = pull_up_IN_clauses(root,
parse-jointree-quals);
+
+ /*
+ * Examine the rtable and inline any stable SQL set returning functions
+ * if possible.
+ */
+ parse-rtable = inline_stable_sql_funcs(parse-rtable);
+
/*
* Check to see if any subqueries in the rangetable can be merged into
* this query.
diff -r -c3 postgres-8.3/src/backend/optimizer/util/clauses.c postgres-8.3-hacked/src/backend/optimizer/util/clauses.c
*** postgres-8.3/src/backend/optimizer/util/clauses.c 2007-09-06 13:31:58.0 -0400
--- postgres-8.3-hacked/src/backend/optimizer/util/clauses.c 2007-10-01 11:49:57.0 -0400
***
*** 101,106
--- 101,117
static void sql_inline_error_callback(void *arg);
static Expr *evaluate_expr(Expr *expr, Oid result_type, int32 result_typmod);
+ static Node *
+ substitute_actual_parameters_srf_inliner_mutator(Node *node,
+ substitute_actual_parameters_context *context);
+ static Query *
+ substitute_actual_parameters_srf_inliner(Query *querytree, int nargs, List *args,
+ int *usecounts);
+ static List * inline_stable_sql_funcs_mutator( List* rtable, eval_const_expressions_context *context);
+ static Query* inline_stable_sql_func(FuncExpr *expr, eval_const_expressions_context *context);
+ List * inline_stable_sql_funcs(List* rtable);
+
+
/*
* OPERATOR clause functions
***
*** 4419,4421
--- 4430,4792
else
return mutator(node, context);
}
+
+ /*
+ * Replace Param nodes with the actual arguments passed to the function.
+ */
+ static Query *
+ substitute_actual_parameters_srf_inliner(Query *querytree, int nargs, List *args,
+ int *usecounts)
+ {
+ substitute_actual_parameters_context context;
+
+ context.nargs = nargs;
+ context.args = args;
+ context.usecounts = usecounts;
+
+ return query_tree_mutator(querytree, substitute_actual_parameters_srf_inliner_mutator, context, 0);
+ }
+
+
+ /*
+ * This mutator cleanses the RTable of function body's to be inlined. Each parameter reference
+ * in the function body must be replaced with the appropriate function argument. Sub-queries
+ * are recursed, and sublink parameters are copied as is.
+ */
+ static Node *
+ substitute_actual_parameters_srf_inliner_mutator(Node *node,
+ substitute_actual_parameters_context *context)
+ {
+ if (node == NULL)
+ return NULL;
+ if (IsA(node, Query))
+ {
+ Query *nquery;
+
+ nquery = query_tree_mutator((Query *) node, substitute_actual_parameters_srf_inliner_mutator, context, 0);
+ return (Node *) nquery;
+ }
+ if (IsA(node, Param))
+ {
+ Param *param = (Param *) node;
+
+ if(param-paramkind == PARAM_SUBLINK )
+ {
+ return copyObject( node );
+ }
+ if (param-paramkind != PARAM_SUBLINK param-paramkind != PARAM_EXTERN)
+ {
+ elog(ERROR, unhanled parameter type);
+ }
+ if (param-paramid = 0 || param-paramid context-nargs)
+ elog(ERROR, invalid paramid: %d, param-paramid);
+
+ /* Count usage of parameter */
+ context-usecounts[param-paramid - 1]++;
+
+ /* Select the appropriate actual arg and replace the Param with it */
+ /* We don't need to copy at this time (it'll get done later) */
+ return list_nth(context-args, param-paramid - 1);
+ }
+ return expression_tree_mutator(node, substitute_actual_parameters_srf_inliner_mutator,
+ (void *) context);
+ }
+
+ /*
+ * Inline stable SQL set-returning functions
+ *
+ *
+ * Takes a function expression as a parameter. If the FuncExpr
+ * is that of a stable SQL set-returning function then we can
+ * replace the function's RTE with a subquery RTE containing the
+ * body of the function. We also recurse into the subqueries RTE
+ *
Re: [PATCHES] TCL fix in HEAD
Marshall, Steve [EMAIL PROTECTED] writes: Bruce Momjian wrote: Can you send in a patch against pltcl.sgml? PL/TCL documentation patch is attached. This seems a bit wordy, as well as wrongly placed --- the time to tell people they need a non-multithreaded Tcl is in the installation instructions. I added the following instead. regards, tom lane Index: installation.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v retrieving revision 1.292 diff -c -r1.292 installation.sgml *** installation.sgml 25 Aug 2007 20:29:25 - 1.292 --- installation.sgml 1 Oct 2007 16:42:50 - *** *** 228,234 listitem para If you want to build the applicationPL/Tcl/application ! procedural language, you of course need a Tcl installation. /para /listitem --- 228,237 listitem para If you want to build the applicationPL/Tcl/application ! procedural language, you of course need a productnameTcl/ ! installation. If you are using a pre-8.4 release of ! productnameTcl/, ensure that it was built without multithreading ! support. /para /listitem ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] TCL fix in HEAD
I'm fine with Tom's wording and placement. This seems a bit wordy, as well as wrongly placed --- the time to tell people they need a non-multithreaded Tcl is in the installation instructions. I added the following instead. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Patch to inline stable SQL set returning UDFs
I discussed this hack with Neil and Josh in Ottawa back in May. I
took a stab at it a few weeks ago and below are the results. It is
mostly modeled after the existing inline_function. The approach taken
is to recursively cleanup the rtable.
I've been testing this in our dev environment for a few weeks now.
I'm sure it still has issues but I think it is about as clean as I can
get it without help from a wider audience. This is my first backend
patch so please be gentle.
I want to thank Neil for answering many of my supremely ignorant
questions on IRC.diff -r -c3 postgres-8.3/src/backend/optimizer/plan/planner.c postgres-8.3-hacked/src/backend/optimizer/plan/planner.c
*** postgres-8.3/src/backend/optimizer/plan/planner.c 2007-05-26 14:23:01.0 -0400
--- postgres-8.3-hacked/src/backend/optimizer/plan/planner.c 2007-10-01 11:49:08.0 -0400
***
*** 256,261
--- 256,268
parse-jointree-quals = pull_up_IN_clauses(root,
parse-jointree-quals);
+
+ /*
+ * Examine the rtable and inline any stable SQL set returning functions
+ * if possible.
+ */
+ parse-rtable = inline_stable_sql_funcs(parse-rtable);
+
/*
* Check to see if any subqueries in the rangetable can be merged into
* this query.
diff -r -c3 postgres-8.3/src/backend/optimizer/util/clauses.c postgres-8.3-hacked/src/backend/optimizer/util/clauses.c
*** postgres-8.3/src/backend/optimizer/util/clauses.c 2007-09-06 13:31:58.0 -0400
--- postgres-8.3-hacked/src/backend/optimizer/util/clauses.c 2007-10-01 11:49:57.0 -0400
***
*** 101,106
--- 101,117
static void sql_inline_error_callback(void *arg);
static Expr *evaluate_expr(Expr *expr, Oid result_type, int32 result_typmod);
+ static Node *
+ substitute_actual_parameters_srf_inliner_mutator(Node *node,
+ substitute_actual_parameters_context *context);
+ static Query *
+ substitute_actual_parameters_srf_inliner(Query *querytree, int nargs, List *args,
+ int *usecounts);
+ static List * inline_stable_sql_funcs_mutator( List* rtable, eval_const_expressions_context *context);
+ static Query* inline_stable_sql_func(FuncExpr *expr, eval_const_expressions_context *context);
+ List * inline_stable_sql_funcs(List* rtable);
+
+
/*
* OPERATOR clause functions
***
*** 4419,4421
--- 4430,4792
else
return mutator(node, context);
}
+
+ /*
+ * Replace Param nodes with the actual arguments passed to the function.
+ */
+ static Query *
+ substitute_actual_parameters_srf_inliner(Query *querytree, int nargs, List *args,
+ int *usecounts)
+ {
+ substitute_actual_parameters_context context;
+
+ context.nargs = nargs;
+ context.args = args;
+ context.usecounts = usecounts;
+
+ return query_tree_mutator(querytree, substitute_actual_parameters_srf_inliner_mutator, context, 0);
+ }
+
+
+ /*
+ * This mutator cleanses the RTable of function body's to be inlined. Each parameter reference
+ * in the function body must be replaced with the appropriate function argument. Sub-queries
+ * are recursed, and sublink parameters are copied as is.
+ */
+ static Node *
+ substitute_actual_parameters_srf_inliner_mutator(Node *node,
+ substitute_actual_parameters_context *context)
+ {
+ if (node == NULL)
+ return NULL;
+ if (IsA(node, Query))
+ {
+ Query *nquery;
+
+ nquery = query_tree_mutator((Query *) node, substitute_actual_parameters_srf_inliner_mutator, context, 0);
+ return (Node *) nquery;
+ }
+ if (IsA(node, Param))
+ {
+ Param *param = (Param *) node;
+
+ if(param-paramkind == PARAM_SUBLINK )
+ {
+ return copyObject( node );
+ }
+ if (param-paramkind != PARAM_SUBLINK param-paramkind != PARAM_EXTERN)
+ {
+ elog(ERROR, unhanled parameter type);
+ }
+ if (param-paramid = 0 || param-paramid context-nargs)
+ elog(ERROR, invalid paramid: %d, param-paramid);
+
+ /* Count usage of parameter */
+ context-usecounts[param-paramid - 1]++;
+
+ /* Select the appropriate actual arg and replace the Param with it */
+ /* We don't need to copy at this time (it'll get done later) */
+ return list_nth(context-args, param-paramid - 1);
+ }
+ return expression_tree_mutator(node, substitute_actual_parameters_srf_inliner_mutator,
+ (void *) context);
+ }
+
+ /*
+ * Inline stable SQL set-returning functions
+ *
+ *
+ * Takes a function expression as a parameter. If the FuncExpr
+ * is that of a stable SQL set-returning function then we can
+ * replace the function's RTE with a subquery RTE containing the
+ * body of the function. We also recurse into the subqueries RTE
+ * looking for inlineable functions within those.
+ *
+ * Returns the inlined function body (Query) if successfull, NULL on failure.
Re: [PATCHES] [HACKERS] Text - C string
As discussed on -hackers, I'm trying to get rid of some redundant code by creating a widely useful set of functions to convert between text and C string in the backend. The new extern functions, declared in include/utils/builtins.h and defined in backend/utils/adt/varlena.c, are: char * text_cstring(const text *t) char * text_cstring_limit(const text *t, int len) text * cstring_text(const char *s) text * cstring_text_limit(const char *s, int len) Within varlena.c, the actual conversions are performed by: char * do_text_cstring(const text *t, const int len) text * do_cstring_text(const char *s, const int len) These functions now do the work for the fmgr functions textin and textout, as well as being directly accessible by backend code. I've searched through the backend for any code which converted between text and C string manually (with memcpy and VARDATA), replacing with calls to one of the four new functions as appropriate. I came across some areas which were using the same, or similar, conversion technique on other varlena data types, such as bytea or xmltype. In cases where the conversion was completely identical I used the new functions. In cases with any differences (even if they seemed minor) I played it safe and left them alone. I'd now like to submit my work so far for review. This patch compiled cleanly on Linux and passed all parallel regression tests. It appears to be performance-neutral based on a few rough tests; I haven't tried to profile the changes in detail. There is still a lot of code out there using DirectFunctionCall1 to call text(in|out)). I've decided to wait for some community feedback on the patch as it stands before replacing those calls. There are a great many, and it would be a shame to have to go through them more than once. I would naively expect that replacing fmgr calls with direct calls would lead to a performance gain (no fmgr overhead), but honestly I'm not sure whether that would actually make a difference. Thanks for your time, BJ text-cstring_1.diff.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] OpenSSL Applink
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: On Mon, Oct 01, 2007 at 10:51:01AM -0400, Tom Lane wrote: I'd vote for backpatching, but only as far as 8.2, seeing that we're abandoning the older branches on Windows. Should we backpatch a version of it to previous versions that does just the error stack manipulation, or just ignore on the grounds that nobody has reported the problem there (it's there, but it's a lot more narrow - I know it's there, but I havent' been able to provoket it due to not knowing enough about setting up certificate chains and such) That's only a cosmetic problem (wrong error message), right? I'd vote for no backpatch, at least for now --- I'd rather see this change get through beta testing first. Anytime you're fooling with interactions with some other package, the risk of portability issues is high. Right. Applied to HEAD. Will wait for a buildfarm cycle to make sure it doesn't kill anything else then try to backport to 8.2 (patch didn't apply cleanly to it) //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Loose check was corrected of win32.mak.
Hi Magnus. Loose check was corrected... and, It notifies an intelligible error message. Regards, Hiroshi Saito win32mak_patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] ecpg thread-safe descriptor
Here is a patch to fix thread-safety of SQL DESCRIPTOR in ecpg. The global variable 'all_descriptors' is split into per-thread vars. There was another idea of splitting into per-connection vars, but I did not do that because there are allocating descriptors before connection and deallocating after disconnection in the regression test. The attached descriptor.pgc is a test case for the issue. It is not included into regression test of ecpg. If this change is acceptable to be applied to HEAD, I'll start backporting recent fixes (prepared statement, memory allocation and descriptor) to 8.2 (and older versions if possible). Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ecpg-descriptor-fix-8.3.patch Description: Binary data descriptor.pgc Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
