Re: [HACKERS] pre-MED
David Fetter da...@fetter.org writes: Tom, I know you've been busy with lots of stuff, so here's a little reminder. I talked with a couple of people who know the back-end much better than I do. One said the above was way under-specified, and the other said he'd started work on it, but hasn't had much time. Since you're the one who brought this up, I think it's on you to flesh it out at least a little bit, or at least to describe it in enough detail that someone else could. I'm sorry, but I have far too much work in front of me reviewing patches that have a chance of getting into 8.4. I do not have time to do pre-implementation research for a patch that doesn't. 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] pre-MED
On Mon, Dec 15, 2008 at 08:50:25AM -0500, Tom Lane wrote: David Fetter da...@fetter.org writes: Tom, I know you've been busy with lots of stuff, so here's a little reminder. I talked with a couple of people who know the back-end much better than I do. One said the above was way under-specified, and the other said he'd started work on it, but hasn't had much time. Since you're the one who brought this up, I think it's on you to flesh it out at least a little bit, or at least to describe it in enough detail that someone else could. I'm sorry, but I have far too much work in front of me reviewing patches that have a chance of getting into 8.4. I do not have time to do pre-implementation research for a patch that doesn't. You took on the responsibility by rejecting the working patch and saying how it should be implemented. That you failed to respond when asked before is very strictly your problem to solve, and I don't mean by bouncing my useful feature. Regards, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] pre-MED
On Mon, 2008-12-15 at 09:12 -0800, David Fetter wrote: On Mon, Dec 15, 2008 at 08:50:25AM -0500, Tom Lane wrote: David Fetter da...@fetter.org writes: Tom, Since you're the one who brought this up, I think it's on you to flesh it out at least a little bit, or at least to describe it in enough detail that someone else could. I'm sorry, but I have far too much work in front of me reviewing patches that have a chance of getting into 8.4. I do not have time to do pre-implementation research for a patch that doesn't. You took on the responsibility by rejecting the working patch and saying how it should be implemented. That you failed to respond when asked before is very strictly your problem to solve, and I don't mean by bouncing my useful feature. As much as I would like to see this feature I believe you are taking the wrong track here David. Tom certainly has no responsibility to you or your patch. This is all volunteer. You catch more flies with honey than with Vinegar. Sincerely, Joshua D. Drake Regards, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- PostgreSQL Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- 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] pre-MED
David Fetter da...@fetter.org writes: On Mon, Dec 15, 2008 at 08:50:25AM -0500, Tom Lane wrote: I'm sorry, but I have far too much work in front of me reviewing patches that have a chance of getting into 8.4. I do not have time to do pre-implementation research for a patch that doesn't. You took on the responsibility by rejecting the working patch and saying how it should be implemented. Working? What you submitted was a self-acknowledged crude hack, which was shortly shown to have several major problems; a quick look in the archives suggests * fails on subplans, and possibly other things that ruleutils.c doesn't support well * not at all clear what to do with aliased column names * requires custom support in each PL, only one of which was actually implemented and there are probably more (I didn't reread the whole thread). The fact that I suggested a possible avenue to fixing some of those problems doesn't make it my responsibility to fix them ... especially not if I don't particularly approve of the hack in the first place. Even with all this fixed it would be a dead-end feature, but we'd be stuck with supporting it forever. You should be happy that I was willing to hold still for accepting the patch if the problems got fixed. 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] pre-MED
On Mon, Nov 17, 2008 at 10:37:41AM -0800, David Fetter wrote: On Tue, Nov 04, 2008 at 12:23:55PM -0500, Tom Lane wrote: Alex Hunsaker bada...@gmail.com writes: On Thu, Oct 30, 2008 at 05:16, Tom Lane t...@sss.pgh.pa.us wrote: which doesn't seem like it would amount to anything compared to the total execution of a plan node, but we do know that ExecProcNode is a hot spot in some usages. Going with the ExecProcNode modification you're proposing, how big would a minimal pre-MED patch be? Tom, I know you've been busy with lots of stuff, so here's a little reminder. I talked with a couple of people who know the back-end much better than I do. One said the above was way under-specified, and the other said he'd started work on it, but hasn't had much time. Since you're the one who brought this up, I think it's on you to flesh it out at least a little bit, or at least to describe it in enough detail that someone else could. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] pre-MED
On Tue, Nov 04, 2008 at 12:23:55PM -0500, Tom Lane wrote: Alex Hunsaker [EMAIL PROTECTED] writes: On Thu, Oct 30, 2008 at 05:16, Tom Lane [EMAIL PROTECTED] wrote: Surely they all have a way to call a SQL function that returns text. Sure but when you call that function you get *that* functions qualifier. And unless there already is a way to grab the parent query qualifiers, the PL specific hacks seem not so bad and very similar to how we have to build trigger arguments for every PL already. The PL hacks are awful :-(, not least because that path leads to randomly different syntax in each PL for exactly the same functionality. As I see it, there are two big problem areas in this patch: 1. How to get the information about restriction clauses to the place where we'd use it; 2. What to do with it once we've got it. We already went over #2 in some detail: the existing ruleutils.c code just isn't very suitable for this purpose. This could probably be worked around, eg drop restriction clauses that contain subplans or outer-relation variables; though I'm quite unsure about the issue of which names to use for the column variables. As for #1, the patch proposes to pass the Plan node (more or less, but that's the key thing) via a new field in ReturnSetInfo. The first problem with that is that it only makes the information available to set-returning functions occurring at the top level of a FunctionScan node. The second problem is that any layer of code we want to pass the information down through has to explicitly know about it, and we have to invent some new API for each one of those layers. ISTM that a saner way to approach this would be to set up a global way to find out what's the currently executing Plan node?. Then this particular problem could be solved by just grabbing the qual field from that node. Infrastructure like that could be useful for instrumentation and debugging purposes as well. I'm not sure about the overhead involved, though. The obvious implementation would add three lines of code to ExecProcNode: PlanState *save_ActivePlanNode = ActivePlanNode; ActivePlanNode = node; ... ActivePlanNode = save_ActivePlanNode; which doesn't seem like it would amount to anything compared to the total execution of a plan node, but we do know that ExecProcNode is a hot spot in some usages. Going with the ExecProcNode modification you're proposing, how big would a minimal pre-MED patch be? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] pre-MED
Alex Hunsaker [EMAIL PROTECTED] writes: On Thu, Oct 30, 2008 at 05:16, Tom Lane [EMAIL PROTECTED] wrote: Surely they all have a way to call a SQL function that returns text. Sure but when you call that function you get *that* functions qualifier. And unless there already is a way to grab the parent query qualifiers, the PL specific hacks seem not so bad and very similar to how we have to build trigger arguments for every PL already. The PL hacks are awful :-(, not least because that path leads to randomly different syntax in each PL for exactly the same functionality. As I see it, there are two big problem areas in this patch: 1. How to get the information about restriction clauses to the place where we'd use it; 2. What to do with it once we've got it. We already went over #2 in some detail: the existing ruleutils.c code just isn't very suitable for this purpose. This could probably be worked around, eg drop restriction clauses that contain subplans or outer-relation variables; though I'm quite unsure about the issue of which names to use for the column variables. As for #1, the patch proposes to pass the Plan node (more or less, but that's the key thing) via a new field in ReturnSetInfo. The first problem with that is that it only makes the information available to set-returning functions occurring at the top level of a FunctionScan node. The second problem is that any layer of code we want to pass the information down through has to explicitly know about it, and we have to invent some new API for each one of those layers. ISTM that a saner way to approach this would be to set up a global way to find out what's the currently executing Plan node?. Then this particular problem could be solved by just grabbing the qual field from that node. Infrastructure like that could be useful for instrumentation and debugging purposes as well. I'm not sure about the overhead involved, though. The obvious implementation would add three lines of code to ExecProcNode: PlanState *save_ActivePlanNode = ActivePlanNode; ActivePlanNode = node; ... ActivePlanNode = save_ActivePlanNode; which doesn't seem like it would amount to anything compared to the total execution of a plan node, but we do know that ExecProcNode is a hot spot in some usages. 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] pre-MED
On Mon, Nov 03, 2008 at 10:02:24AM -0300, Alvaro Herrera wrote: David Fetter wrote: However, there are little lacunæ like this: SELECT * FROM show_qual() s(a) WHERE A NOT IN ( SELECT 'foo' UNION ALL SELECT 'bar' ); a (NOT (hashed subplan)) This little lacuna seems to say that if you pass the wrong query to dblink, it will fail to work, possibly with a very obscure error message; it will be very difficult to debug, and also very difficult (if not impossible) to workaround. I understand that a full implementation of SQL/MED will involve just about every part of PostgreSQL, but we've got a case of le mieux est l'enemi du bien with this contrived example, which I included so people could be fully informed when using this very helpful new feature. Left out are the very large benefits that, for example, dblink gets for free. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] pre-MED
Alvaro Herrera [EMAIL PROTECTED] writes: David Fetter wrote: However, there are little lacunæ like this: SELECT * FROM show_qual() s(a) WHERE A NOT IN ( SELECT 'foo' UNION ALL SELECT 'bar' ); a (NOT (hashed subplan)) This little lacuna seems to say that if you pass the wrong query to dblink, it will fail to work, possibly with a very obscure error message; it will be very difficult to debug, and also very difficult (if not impossible) to workaround. Yeah. The problem here is that the portions of ruleutils.c that deal with executable plan trees (as opposed to parser output) have never been designed or intended to do more than support EXPLAIN --- which means that human readable has been considered not only sufficient but more important than 100% correct and mechanically re-parseable. The proposed patch raises the bar enormously. I'm not even real sure what all the issues would be, but I'm pretty sure that subplans are just the tip of the iceberg. Occurrences of Params ($n) would definitely be another failure case, and I also wonder what would happen with join clauses (containing references to the outer side of a join). 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] pre-MED
David Fetter wrote: I understand that a full implementation of SQL/MED will involve just about every part of PostgreSQL, but we've got a case of le mieux est l'enemi du bien with this contrived example, which I included so people could be fully informed when using this very helpful new feature. Left out are the very large benefits that, for example, dblink gets for free. That's all fine and dandy, as long as the deparser is able to notice when it's going to emit an invalid qualification, and spits out NULL instead (does your code handle that case?). If it cannot, then we would cause a serious regression -- dblink fails to work just because the query happens to use a construct that does not lend itself to proper deparsing. -- 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] pre-MED
David Fetter [EMAIL PROTECTED] writes: Left out are the very large benefits that, for example, dblink gets for free. I take it that works reliably isn't a property you think dblink needs to have. 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] pre-MED
I wrote: ... I'm not even real sure what all the issues would be, but I'm pretty sure that subplans are just the tip of the iceberg. Another issue is that ruleutils responds to column aliasing, as indeed it must to generate correct output for rules: regression=# explain select * from tenk1 a where a.unique1 = 42; QUERY PLAN --- Index Scan using tenk1_unique1 on tenk1 a (cost=0.00..8.27 rows=1 width=244) Index Cond: (unique1 = 42) (2 rows) regression=# explain select * from tenk1 a(foo) where a.foo = 42; QUERY PLAN --- Index Scan using tenk1_unique1 on tenk1 a (cost=0.00..8.27 rows=1 width=244) Index Cond: (foo = 42) (2 rows) This would be a bit of a problem for dblink or similar functions, which would have no way at all to know how the column names that they are dealing in got renamed. 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] pre-MED
David Fetter wrote: However, there are little lacunæ like this: SELECT * FROM show_qual() s(a) WHERE A NOT IN ( SELECT 'foo' UNION ALL SELECT 'bar' ); a (NOT (hashed subplan)) This little lacuna seems to say that if you pass the wrong query to dblink, it will fail to work, possibly with a very obscure error message; it will be very difficult to debug, and also very difficult (if not impossible) to workaround. -- 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] pre-MED
On Fri, Oct 31, 2008 at 07:48, David Fetter [EMAIL PROTECTED] wrote:
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
I was assigned to review this. A few comments beside the ones Alavaro
and Tom pointed out...
select * from dblink('select * from foo');
segfaults due to rsi in dblink_record_internal() never being
initialized. You probably know that though and are just trying to
show how dblink could use it...
select * from dblink('select * from foo where..') s(a) where ...;
seems like it will fail (due to the 2 where clauses) with a strange
error message (though its hard to tell without documentation :))
Why the where clause and not table/joins/target list etc?
Maybe instead of having this for PL's we should just keep the part
that composes the qualifiers into strings (rsinfo_get_qual_str()) so
that only contrib modules can use it? And for now dblink will just be
the only user? Or what exactly is the use case for PL languages to
have it? SQL/MED ?
I started following http://wiki.postgresql.org/wiki/Reviewing_a_Patch.
But it felt useless until you make Tom and Alavaro happy :) Or at
least I have a patch that I can play with :)
--
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] pre-MED
On Thu, Oct 30, 2008 at 05:16, Tom Lane [EMAIL PROTECTED] wrote: David Fetter [EMAIL PROTECTED] writes: On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote: I would argue that it's already designed wrong if there's need for PL-specific implementation effort. I'm not sure how else to do this. The current implementation returns char *, which doesn't translate uniformly into the PLs. Surely they all have a way to call a SQL function that returns text. Sure but when you call that function you get *that* functions qualifier. And unless there already is a way to grab the parent query qualifiers, the PL specific hacks seem not so bad and very similar to how we have to build trigger arguments for every PL already. -- 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] pre-MED
On Wed, Oct 29, 2008 at 09:40:00AM -0700, David Fetter wrote:
Folks,
Please find enclosed a WIP patch to add the ability for functions to
see the qualifiers of the query in which they're called. It's not
working just yet, and I'm not sure how best to get it working, but I'd
like to see this as part of 8.4, as SQL/MED is just way too ambitious
given the time frame.
Any tips, hints, pointers, etc. would be much appreciated.
Also, PL/Perl shouldn't be the only language to have this capability.
How might we add similar capabilities to PL/PythonU and PL/Tcl? To
the rest of the PLs? Would it make any sense to have it in SQL
language functions?
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
CREATE OR REPLACE FUNCTION show_qual()
RETURNS TEXT
LANGUAGE plperl
AS $$
return $_QUAL-{qual_string};
$$;
postgres=# SELECT * FROM show_qual() s(a) where a like '%';
a
--
(a ~~ '%'::text)
However, there are little lacunæ like this:
SELECT * FROM show_qual() s(a)
WHERE A NOT IN (
SELECT 'foo' UNION ALL SELECT 'bar'
);
a
(NOT (hashed subplan))
Cheers,
David.
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: [EMAIL PROTECTED]
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
index 7a9ddcd..c5b35be 100644
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/dblink.c
@@ -728,6 +728,7 @@ dblink_record_internal(FunctionCallInfo fcinfo, bool
is_async, bool do_get)
char *conname = NULL;
remoteConn *rconn = NULL;
boolfail = true;/* default to backward
compatible */
+ ReturnSetInfo *rsi; /* set up for qual-pushing */
/* create a function context for cross-call persistence */
funcctx = SRF_FIRSTCALL_INIT();
@@ -802,6 +803,17 @@ dblink_record_internal(FunctionCallInfo fcinfo, bool
is_async, bool do_get)
elog(ERROR, wrong number of arguments);
}
+ if (sql rsi-qual) /* add qualifiers if available. */
+ {
+ char *quals = rsinfo_get_qual_str(rsi);
+ char *qualifiedQuery = palloc(strlen(sql) + strlen(
WHERE ) +
+
strlen(quals) + 1);
+
+ sprintf(qualifiedQuery, %s WHERE %s, sql, quals);
+
+ sql = qualifiedQuery;
+ }
+
if (!conn)
DBLINK_CONN_NOT_AVAIL;
diff --git a/src/backend/executor/execQual.c b/src/backend/executor/execQual.c
index 4c4742d..571b2ae 100644
--- a/src/backend/executor/execQual.c
+++ b/src/backend/executor/execQual.c
@@ -45,6 +45,7 @@
#include miscadmin.h
#include nodes/makefuncs.h
#include nodes/nodeFuncs.h
+#include optimizer/clauses.h
#include optimizer/planmain.h
#include pgstat.h
#include utils/acl.h
@@ -1693,6 +1694,27 @@ ExecMakeFunctionResultNoSets(FuncExprState *fcache,
return result;
}
+/*
+ *
+ * rsinfo_get_qual_str
+ *
+ * Get either an empty string or a batch of qualifiers.
+ *
+ */
+char *
+rsinfo_get_qual_str(ReturnSetInfo *rsinfo)
+{
+ Node*qual;
+ List*context;
+
+ if (!rsinfo-qual || !rsinfo-plan)
+ return pstrdup();
+
+ qual = (Node *) make_ands_explicit(rsinfo-qual);
+ context = deparse_context_for_plan((Node *) rsinfo-plan, NULL,
rsinfo-rtable, NULL);
+
+ return deparse_expression(qual, context, false, false);
+}
/*
* ExecMakeTableFunctionResult
@@ -1703,6 +1725,7 @@ ExecMakeFunctionResultNoSets(FuncExprState *fcache,
Tuplestorestate *
ExecMakeTableFunctionResult(ExprState *funcexpr,
ExprContext *econtext,
+ Plan *plan, List
*rtable,
TupleDesc expectedDesc,
bool randomAccess)
{
@@ -1719,6 +1742,7 @@ ExecMakeTableFunctionResult(ExprState *funcexpr,
MemoryContext oldcontext;
booldirect_function_call;
boolfirst_time = true;
+ List*qual = plan-qual;
callerContext = CurrentMemoryContext;
@@ -1736,6 +1760,9 @@ ExecMakeTableFunctionResult(ExprState *funcexpr,
InitFunctionCallInfoData(fcinfo, NULL, 0, NULL, (Node *) rsinfo);
rsinfo.type = T_ReturnSetInfo;
rsinfo.econtext = econtext;
+ rsinfo.qual = qual;
+ rsinfo.rtable = rtable;
+
Re: [HACKERS] pre-MED
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
CREATE OR REPLACE FUNCTION show_qual()
RETURNS TEXT
LANGUAGE plperl
AS $$
return $_QUAL-{qual_string};
$$;
I thought the point here was to change the basic interface to an SQL
function which PL/perl or any other language could access in the usual
way. All this does is keep the strange, magical interface but then
use PL/perl to put a more normal looking wrapper around it.
...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] pre-MED
On Fri, Oct 31, 2008 at 01:37:00PM -0400, Robert Haas wrote:
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
CREATE OR REPLACE FUNCTION show_qual()
RETURNS TEXT
LANGUAGE plperl
AS $$
return $_QUAL-{qual_string};
$$;
I thought the point here was to change the basic interface to an SQL
function which PL/perl or any other language could access in the
usual way. All this does is keep the strange, magical interface but
then use PL/perl to put a more normal looking wrapper around it.
It's not clear how that would work. If you have ideas, please say :)
Cheers,
David.
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: [EMAIL PROTECTED]
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
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] pre-MED
Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote: Also, PL/Perl shouldn't be the only language to have this capability. How might we add similar capabilities to PL/PythonU I'll look at adding this to pl/pythonu. I would argue that it's already designed wrong if there's need for PL-specific implementation effort. I would agree. This should be a generic API. Joshua D. Drake 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] pre-MED
David Fetter [EMAIL PROTECTED] writes: On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote: I would argue that it's already designed wrong if there's need for PL-specific implementation effort. I'm not sure how else to do this. The current implementation returns char *, which doesn't translate uniformly into the PLs. Surely they all have a way to call a SQL function that returns text. 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] pre-MED
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter [EMAIL PROTECTED] wrote: Please find enclosed a WIP patch to add the ability for functions to see the qualifiers of the query in which they're called. It's not working just yet, and I'm not sure how best to get it working, but I'd like to see this as part of 8.4, as SQL/MED is just way too ambitious given the time frame. To be more specific, SQL/MED is going to be 8.5. This is an overall improvement for accessing the predicate. -- Jonah H. Harris, Senior DBA myYearbook.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] pre-MED
On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote: Folks, Please find enclosed a WIP patch to add the ability for functions to see the qualifiers of the query in which they're called. It's not working just yet, and I'm not sure how best to get it working, but I'd like to see this as part of 8.4, as SQL/MED is just way too ambitious given the time frame. Any tips, hints, pointers, etc. would be much appreciated. Also, PL/Perl shouldn't be the only language to have this capability. How might we add similar capabilities to PL/PythonU I'll look at adding this to pl/pythonu. I have to finish some stuff there before freeze anyway. -- Hannu -- 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] pre-MED
On Wed, 2008-10-29 at 19:17 +0200, Hannu Krosing wrote: On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote: Folks, Please find enclosed a WIP patch to add the ability for functions to see the qualifiers of the query in which they're called. It's not working just yet, and I'm not sure how best to get it working, but I'd like to see this as part of 8.4, as SQL/MED is just way too ambitious given the time frame. Any tips, hints, pointers, etc. would be much appreciated. Also, PL/Perl shouldn't be the only language to have this capability. How might we add similar capabilities to PL/PythonU I'll look at adding this to pl/pythonu. I have to finish some stuff there before freeze anyway. Have we tested plpython with version 3? -- Hannu -- -- 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] pre-MED
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter [EMAIL PROTECTED] wrote: Also, PL/Perl shouldn't be the only language to have this capability. How might we add similar capabilities to PL/PythonU and PL/Tcl? To the rest of the PLs? Would it make any sense to have it in SQL language functions? Here's a vote for allowing this in plain SQL. I use the tablefunc contrib module as a way to build a view of a specific questionnaire's responses (using Elein's nice model here [1]). Currently, if I then write queries against these views that include WHERE clauses they don't perform very well as the underlying data size grows. I was using the afore-mentioned large view that casts everything to text, but recently I started using separate calls to the crosstab function for each underlying table, then joining them together based on their response ID. This seems to work much better for more complex queries, but I think it would still be beneficial to have access to these qualifiers so I could push down to each subquery the list of response ID's to pull. I don't have access to sample SQL at the moment, but if it is wanted I can try to get that this week. David Blewett 1. http://www.varlena.com/GeneralBits/110.php -- 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] pre-MED
On Wed, 2008-10-29 at 10:33 -0700, Joshua D. Drake wrote: On Wed, 2008-10-29 at 19:17 +0200, Hannu Krosing wrote: On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote: Folks, Please find enclosed a WIP patch to add the ability for functions to see the qualifiers of the query in which they're called. It's not working just yet, and I'm not sure how best to get it working, but I'd like to see this as part of 8.4, as SQL/MED is just way too ambitious given the time frame. Any tips, hints, pointers, etc. would be much appreciated. Also, PL/Perl shouldn't be the only language to have this capability. How might we add similar capabilities to PL/PythonU I'll look at adding this to pl/pythonu. I have to finish some stuff there before freeze anyway. Have we tested plpython with version 3? If you mean python 3.0 , then no, at least I have not tested it yet. not even 2.6 -- -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- 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] pre-MED
Hannu Krosing [EMAIL PROTECTED] writes: On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote: Also, PL/Perl shouldn't be the only language to have this capability. How might we add similar capabilities to PL/PythonU I'll look at adding this to pl/pythonu. I would argue that it's already designed wrong if there's need for PL-specific implementation effort. 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] pre-MED
David Blewett [EMAIL PROTECTED] writes: Here's a vote for allowing this in plain SQL. I use the tablefunc contrib module as a way to build a view of a specific questionnaire's responses (using Elein's nice model here [1]). Currently, if I then write queries against these views that include WHERE clauses they don't perform very well as the underlying data size grows. I was using the afore-mentioned large view that casts everything to text, but recently I started using separate calls to the crosstab function for each underlying table, then joining them together based on their response ID. This seems to work much better for more complex queries, but I think it would still be beneficial to have access to these qualifiers so I could push down to each subquery the list of response ID's to pull. I don't have access to sample SQL at the moment, but if it is wanted I can try to get that this week. Please. Some real use-cases would be very helpful here. I'm particularly wondering whether the proposed deparse call actually yields anything that's useful without extensive additional knowledge about the query ... 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] pre-MED
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote: Hannu Krosing [EMAIL PROTECTED] writes: On Wed, 2008-10-29 at 09:40 -0700, David Fetter wrote: Also, PL/Perl shouldn't be the only language to have this capability. How might we add similar capabilities to PL/PythonU I'll look at adding this to pl/pythonu. I would argue that it's already designed wrong if there's need for PL-specific implementation effort. I'm not sure how else to do this. The current implementation returns char *, which doesn't translate uniformly into the PLs. More sophisticated implementations--a tree or forest structure including ANDs and ORs, etc.--are even less uniform to translate into PLs, at least as far as I can tell. The way I'm looking at it, this could be added onto SPI at varying degrees of sophistication, but there would still be PL-specific bindings for it, each of which would involve a PL-specific implementation effort. What big things have I missed here? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
