Re: row literal problem

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Merlin Moncure <mmoncure@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-07-18T20:42:48Z
Lists: pgsql-hackers
On 07/18/2012 03:30 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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?
>> No, the inner query has two fields.
>> It happens for all rows, but not for all two-field-resulting queries as
>> q. I'm trying to find a simple case rather than the rather complex query
>> my customer is using.
> I'm wondering about a rowtype with a third, dropped column.


As usual Tom has hit the nail on the head. Here's a simple test case 
that demonstrates the problem. I could probably have cut it down more 
but I was following the structure of the original somewhat:

    # with q as
    (
    select max(nspname) as nspname, sum(allind.count) as indices
        from (select indrelid, count(*)
              from pg_index
      group by indrelid) allind
          left outer join pg_class on pg_class.oid = allind.indrelid
      left outer join pg_namespace on pg_class.relnamespace =
    pg_namespace.oid
        group by pg_namespace.oid
    )
    select q from q;

              q
    --------------------
      (pg_catalog,91,11)
      (pg_toast,18,99)
    (2 rows)


cheers

andrew



>
> 			regards, tom lane
>