Andrew Dunstan writes:
> On 02/08/2012 11:20 AM, Tom Lane wrote:
>> I am going to go ahead and commit the patch with the altered json
>> results, because IMO it is mere accident that these regression cases
>> were coming out with "nice" field labels anyway. When and if Andrew
>> gets the RowExp
On 02/08/2012 11:20 AM, Tom Lane wrote:
I am going to go ahead and commit the patch with the altered json
results, because IMO it is mere accident that these regression cases
were coming out with "nice" field labels anyway. When and if Andrew
gets the RowExpr cases fixed properly, that will s
On Wed, Feb 8, 2012 at 18:20, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp wrote:
>>> Patch attached (in git am format). Passes all regression tests (except
>>> 'json' which fails on my machine even on git master).
>
>> Can you provide the diffs from th
Robert Haas writes:
> On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp wrote:
>> Patch attached (in git am format). Passes all regression tests (except
>> 'json' which fails on my machine even on git master).
> Can you provide the diffs from the json test on your machine? I don't
> see any build-
On Wed, Feb 8, 2012 at 4:53 AM, Marti Raudsepp wrote:
> Patch attached (in git am format). Passes all regression tests (except
> 'json' which fails on my machine even on git master).
Can you provide the diffs from the json test on your machine? I don't
see any build-farm failures off-hand...
--
On Wed, Feb 8, 2012 at 06:21, Tom Lane wrote:
> Marti Raudsepp writes:
>> Case #1 uses the normal textcat(text, text) operator by automatically
>> coercing 'x' as text.
>> However, case #2 uses the anytextcat(anynonarray, text), which is
>> marked as volatile thus acts as an optimization barrier.
Marti Raudsepp writes:
> Case #1 uses the normal textcat(text, text) operator by automatically
> coercing 'x' as text.
> However, case #2 uses the anytextcat(anynonarray, text), which is
> marked as volatile thus acts as an optimization barrier.
Hmm ... since those operators were invented (in 8.3
On 02/07/2012 03:36 PM, Marti Raudsepp wrote:
On Tue, Feb 7, 2012 at 22:31, Andrew Dunstan wrote:
It gets worse if you replace the expression with a call to a (non-sql)
function returning text, which was in fact the original use case. Then
you're pretty much hosed.
Oh, if it's a non-SQL fun
On Tue, Feb 7, 2012 at 22:31, Andrew Dunstan wrote:
> It gets worse if you replace the expression with a call to a (non-sql)
> function returning text, which was in fact the original use case. Then
> you're pretty much hosed.
Oh, if it's a non-SQL function then marking it as STABLE/IMMUTABLE
sho
On 02/07/2012 03:18 PM, Marti Raudsepp wrote:
Hi list,
Andrew Dunstan reported an awkward-seeming case on IRC where shifting
around a concatenation expression in a view made the planner choose a
good or a bad execution plan.
Simplified, it boils down to this:
db=# create table foo(i int);
db
Hi list,
Andrew Dunstan reported an awkward-seeming case on IRC where shifting
around a concatenation expression in a view made the planner choose a
good or a bad execution plan.
Simplified, it boils down to this:
db=# create table foo(i int);
db=# explain verbose select i from (select i, i::tex
11 matches
Mail list logo
