Thread: pre-MED
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? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachment
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter <david@fetter.org> 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
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
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 > > > --
On Wed, Oct 29, 2008 at 12:40 PM, David Fetter <david@fetter.org> 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
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
Hannu Krosing <hannu@krosing.net> 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
"David Blewett" <david@dawninglight.net> 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
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote: > Hannu Krosing <hannu@krosing.net> 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 <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Tom Lane wrote: > Hannu Krosing <hannu@krosing.net> 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 >
David Fetter <david@fetter.org> 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
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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachment
> 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
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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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 <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Alvaro Herrera <alvherre@commandprompt.com> 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
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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
David Fetter <david@fetter.org> 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
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
On Fri, Oct 31, 2008 at 07:48, David Fetter <david@fetter.org> 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
Alavarohappy :) Or at
least I have a patch that I can play with :)
On Thu, Oct 30, 2008 at 05:16, Tom Lane <tgl@sss.pgh.pa.us> wrote: > David Fetter <david@fetter.org> 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.
"Alex Hunsaker" <badalex@gmail.com> writes:
> On Thu, Oct 30, 2008 at 05:16, Tom Lane <tgl@sss.pgh.pa.us> 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
On Tue, Nov 04, 2008 at 12:23:55PM -0500, Tom Lane wrote: > "Alex Hunsaker" <badalex@gmail.com> writes: > > On Thu, Oct 30, 2008 at 05:16, Tom Lane <tgl@sss.pgh.pa.us> 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 <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
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" <badalex@gmail.com> writes: > > > On Thu, Oct 30, 2008 at 05:16, Tom Lane <tgl@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 <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@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
On Mon, Dec 15, 2008 at 08:50:25AM -0500, Tom Lane wrote: > David Fetter <david@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 <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
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 <david@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 <david@fetter.org> http://fetter.org/ > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter > Skype: davidfetter XMPP: david.fetter@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
David Fetter <david@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
allclear 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