On Sun, Jul 26, 2009 at 7:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> Here's the update. There are a few things that I'm not entirely happy
>> with here, but not quite sure what to do about either.
>
> Committed with a few editorializations.
Thanks.
>> - ExplainPrintPlan() is now almost tri
Robert Haas writes:
> Here's the update. There are a few things that I'm not entirely happy
> with here, but not quite sure what to do about either.
Committed with a few editorializations.
> - ExplainPrintPlan() is now almost trivial. It seems like there
> should be some way to get rid of this
On Thu, Jul 23, 2009 at 12:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> Ugh. I took a look at this and it turns out that there are some
>> tentacles. It doesn't seem very sane to actually do anything with a
>> list of DefElem nodes, so we really need to parse that list and
>> convert it to a
Robert Haas writes:
> Ugh. I took a look at this and it turns out that there are some
> tentacles. It doesn't seem very sane to actually do anything with a
> list of DefElem nodes, so we really need to parse that list and
> convert it to a more sensible format right away (this also seems
> impor
On Tue, Jul 21, 2009 at 10:29 PM, Robert Haas wrote:
> On Tue, Jul 21, 2009 at 10:05 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane wrote:
Also, I'd suggest changing the ExplainStmt struct to have a list of
DefElem options instead of hard-wiring
On Tue, Jul 21, 2009 at 10:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane wrote:
>>> Also, I'd suggest changing the ExplainStmt struct to have a list of
>>> DefElem options instead of hard-wiring the option set at that level.
>
>> What is the advantage of
Robert Haas writes:
> On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane wrote:
>> Also, I'd suggest changing the ExplainStmt struct to have a list of
>> DefElem options instead of hard-wiring the option set at that level.
> What is the advantage of that?
Fewer places to change when you add a new option;
On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> Here is an updated version of my "generic options for explain" patch.
>
> What is the rationale for essentially duplicating defGetBoolean()?
I just didn't realize we already had something along those lines.
Updated patch at
Robert Haas writes:
> Here is an updated version of my "generic options for explain" patch.
What is the rationale for essentially duplicating defGetBoolean()?
Also, I'd suggest changing the ExplainStmt struct to have a list of
DefElem options instead of hard-wiring the option set at that level.
On Sun, Jul 19, 2009 at 9:47 AM, Andres Freund wrote:
> On Sunday 19 July 2009 14:39:33 Martijn van Oosterhout wrote:
>> On Sun, Jul 19, 2009 at 03:15:38AM +0200, Andres Freund wrote:
>> > Hi Robert, Hi All,
>> >
>> > Patch applies with some offset changes, code changes look sensible, I
>> > person
On Sunday 19 July 2009 14:39:33 Martijn van Oosterhout wrote:
> On Sun, Jul 19, 2009 at 03:15:38AM +0200, Andres Freund wrote:
> > Hi Robert, Hi All,
> >
> > Patch applies with some offset changes, code changes look sensible, I
> > personally like the new syntax and the features it may allow in fut
On Sun, Jul 19, 2009 at 03:15:38AM +0200, Andres Freund wrote:
> Hi Robert, Hi All,
>
> Patch applies with some offset changes, code changes look sensible, I
> personally like the new syntax and the features it may allow in future. One,
> possibly big, gripe remains though:
> The formerly valid
Hi Robert, Hi All,
Patch applies with some offset changes, code changes look sensible, I
personally like the new syntax and the features it may allow in future. One,
possibly big, gripe remains though:
The formerly valid statement which cannot be written without the parentheses
and stay semanti
Here is an updated version of my "generic options for explain" patch.
Previous version here:
http://archives.postgresql.org/pgsql-hackers/2009-06/msg00866.php
This patch requires the "explain refactoring v4" patch, which you can
find here, to be applied first:
http://archives.postgresql.org/pgsq
14 matches
Mail list logo
