Tom Lane writes:
> Now you might suggest that the function itself is redundant with the
> information given in the FunctionScan node line and so we need only
> show the argument list. Unfortunately there are cases where this fails;
> in particular, the named function could have been "inlined" by
Dimitri Fontaine writes:
> Argument List?
Well, as shown in the example I posted, it's not just the argument list
but the whole call:
>> Function Call: unnest(ARRAY[ROW(('1.2.2'::text)::semver, '='::text,
>> ('1.2.2'::text)::semver), ROW('1.2.23', '=', '1.2.23')])
Now you might suggest that th
Argument List?
--
dim
Le 24 août 2010 à 18:06, Tom Lane a écrit :
> I wrote:
>> Robert Haas writes:
>>> If you try to put all that on the same line, I think it might get
>>> awkwardly long. Perhaps something like:
>
>>> Function Scan on function_name
>>> Expression: function_name(function_a
"David E. Wheeler" writes:
> On Aug 24, 2010, at 10:21 AM, Tom Lane wrote:
>> The order was bothering me a bit too, but there's a generic decision
>> in there that the tlist is shown before any node-type-specific items.
>> Not sure that we want to move it to the bottom for all of them.
> Does it
On Aug 24, 2010, at 10:21 AM, Tom Lane wrote:
>> This may be the ultimate bike-shed but Wouldn't this be clearer the
>> other way around? I generally think input comes first and then output.
>
> The order was bothering me a bit too, but there's a generic decision
> in there that the tlist is show
On Tue, Aug 24, 2010 at 1:21 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Tue, Aug 24, 2010 at 5:06 PM, Tom Lane wrote:
>>> Function Scan on pg_catalog.unnest f (cost=0.00..1.50 rows=100 width=96)
>>> Output: (((lv)::text || op) || (rv)::text)
>>> Function Call: unnest(ARRAY[ROW(('1.2.2'
Greg Stark writes:
> On Tue, Aug 24, 2010 at 5:06 PM, Tom Lane wrote:
>> Function Scan on pg_catalog.unnest f (cost=0.00..1.50 rows=100 width=96)
>> Output: (((lv)::text || op) || (rv)::text)
>> Function Call: unnest(ARRAY[ROW(('1.2.2'::text)::semver, '='::text,
>> ('1.2.2'::text)::semver)
On Tue, Aug 24, 2010 at 5:06 PM, Tom Lane wrote:
> Function Scan on pg_catalog.unnest f (cost=0.00..1.50 rows=100 width=96)
> Output: (((lv)::text || op) || (rv)::text)
> Function Call: unnest(ARRAY[ROW(('1.2.2'::text)::semver, '='::text,
> ('1.2.2'::text)::semver), ROW('1.2.23', '=', '1.2.
On Tue, Aug 24, 2010 at 12:06:34PM -0400, Tom Lane wrote:
> I wrote:
> > Robert Haas writes:
> >> If you try to put all that on the same line, I think it might get
> >> awkwardly long. Perhaps something like:
>
> >> Function Scan on function_name
> >> Expression: function_name(function_arg1, fun
I wrote:
> Robert Haas writes:
>> If you try to put all that on the same line, I think it might get
>> awkwardly long. Perhaps something like:
>> Function Scan on function_name
>> Expression: function_name(function_arg1, function_arg2, ...)
> Yeah, that's what I had in mind, but I'm still fumbl
Excerpts from Tom Lane's message of mar ago 24 11:36:50 -0400 2010:
> Andres Freund writes:
> > On Tuesday 24 August 2010 16:40:30 Tom Lane wrote:
> >> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> >> report. Seems like this would be a good thing to print. Should
> >> it ap
On Tuesday 24 August 2010 17:36:50 Tom Lane wrote:
> Andres Freund writes:
> > On Tuesday 24 August 2010 16:40:30 Tom Lane wrote:
> >> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> >> report. Seems like this would be a good thing to print. Should
> >> it appear always, or j
Andres Freund writes:
> On Tuesday 24 August 2010 16:40:30 Tom Lane wrote:
>> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
>> report. Seems like this would be a good thing to print. Should
>> it appear always, or just with VERBOSE, or ???
> I vote for only showing it with v
Robert Haas writes:
> If you try to put all that on the same line, I think it might get
> awkwardly long. Perhaps something like:
> Function Scan on function_name
>Expression: function_name(function_arg1, function_arg2, ...)
Yeah, that's what I had in mind, but I'm still fumbling for the ri
Hi,
On Tuesday 24 August 2010 16:40:30 Tom Lane wrote:
> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> report. Seems like this would be a good thing to print. Should
> it appear always, or just with VERBOSE, or ???
I vote for only showing it with verbose - not that its a ne
On Tue, Aug 24, 2010 at 11:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 24, 2010 at 10:56 AM, Robert Haas wrote:
>>> I think showing it always is reasonable. I'd like to see it printed
>>> in a form such that casting to regproc will succeed.
>
>> On second thought, that second se
Robert Haas writes:
> On Tue, Aug 24, 2010 at 10:56 AM, Robert Haas wrote:
>> I think showing it always is reasonable. I'd like to see it printed
>> in a form such that casting to regproc will succeed.
> On second thought, that second sentence may not make sense.
It does not, because it's not
On Tue, Aug 24, 2010 at 10:56 AM, Robert Haas wrote:
> On Tue, Aug 24, 2010 at 10:40 AM, Tom Lane wrote:
>> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
>> report. Seems like this would be a good thing to print. Should
>> it appear always, or just with VERBOSE, or ???
>
> I
On Tue, Aug 24, 2010 at 10:40 AM, Tom Lane wrote:
> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> report. Seems like this would be a good thing to print. Should
> it appear always, or just with VERBOSE, or ???
I think showing it always is reasonable. I'd like to see it pr
On Tue, Aug 24, 2010 at 10:40:30AM -0400, Tom Lane wrote:
> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> report. Seems like this would be a good thing to print. Should
> it appear always, or just with VERBOSE, or ???
+1 for always.
Cheers,
David.
--
David Fetter http://
So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
report. Seems like this would be a good thing to print. Should
it appear always, or just with VERBOSE, or ???
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
21 matches
Mail list logo
