Merlin Moncure writes:
> On Fri, Jul 20, 2012 at 1:31 AM, Tom Lane wrote:
>> Here's a draft patch for that. It wasn't quite as ugly as I feared.
>> A lot of the apparent bulk of the patch is because I chose to split
>> ExecEvalVar into separate functions for the scalar and whole-row
>> cases, wh
On Fri, Jul 20, 2012 at 1:31 AM, Tom Lane wrote:
> I wrote:
>> I think the way to solve this is to do whatever it takes to get access
>> to the subplan targetlist. We could then do something a bit cleaner
>> than what the named-rowtype code is currently doing: if there are
>> resjunk columns in t
I wrote:
> I think the way to solve this is to do whatever it takes to get access
> to the subplan targetlist. We could then do something a bit cleaner
> than what the named-rowtype code is currently doing: if there are
> resjunk columns in the subplan targetlist, use the tlist to create a
> JunkF
Merlin Moncure writes:
> here's a cut down example:
> with q as (select max(v) from (select 1 as v) q group by v) select q from q;
I traced through this example, and find that it's another issue in an
area we've hacked at before. ExecEvalVar, when it finds that it's
dealing with a whole-row Var
Merlin Moncure writes:
> hm, it's the 'group by' -- for example if you add group by
> pg_namespace.oid, group by pg_namespace.oid || 'abc', you can invent
> columns that come back into the rowtype.
Yeah, the whole-row variable is evidently picking up "resjunk" columns
from the inner query. Haven
On Wed, Jul 18, 2012 at 3:56 PM, Merlin Moncure wrote:
> hm, it's the 'group by' -- for example if you add group by
> pg_namespace.oid, group by pg_namespace.oid || 'abc', you can invent
> columns that come back into the rowtype.
here's a cut down example:
with q as (select max(v) from (select 1
On Wed, Jul 18, 2012 at 3:42 PM, Andrew Dunstan wrote:
>
> On 07/18/2012 03:30 PM, Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>>
>>> On 07/18/2012 03:18 PM, Merlin Moncure wrote:
there are no null fields, right? if the last field is sometimes null
you'd see that (you probably ru
On 07/18/2012 03:30 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 07/18/2012 03:18 PM, Merlin Moncure wrote:
there are no null fields, right? if the last field is sometimes null
you'd see that (you probably ruled that out though). when you say
'sometimes', do you mean for some rows and not o
Andrew Dunstan writes:
> On 07/18/2012 03:18 PM, Merlin Moncure wrote:
>> there are no null fields, right? if the last field is sometimes null
>> you'd see that (you probably ruled that out though). when you say
>> 'sometimes', do you mean for some rows and not others? or for some
>> queries?
>
On 07/18/2012 03:18 PM, Merlin Moncure wrote:
On Wed, Jul 18, 2012 at 1:58 PM, Andrew Dunstan wrote:
I'm chasing up an issue from a client who has this problem (in 9.1):
with q as
(
some query here
)
select q.* from q
yields:
job_scope | checked_co
On Wed, Jul 18, 2012 at 1:58 PM, Andrew Dunstan wrote:
> I'm chasing up an issue from a client who has this problem (in 9.1):
>
> with q as
> (
> some query here
> )
> select q.* from q
>
> yields:
>
>job_scope | checked_col
> -
I'm chasing up an issue from a client who has this problem (in 9.1):
with q as
(
some query here
)
select q.* from q
yields:
job_scope | checked_col
---+--
Co Revenues:
12 matches
Mail list logo
