Re: [HACKERS] Parser bug?

> Bruce Momjian wrote:
> ...
>   >>   >> bray=> select rcname, rcsrc from pg_relcheck where rcrelid =
>   >>   >> '115404'::oid and rcrelid in (select min(rcrelid) from pg_relcheck
>   >>   >> group by rcname); ERROR:  parser: Subselect has too many or too
>   >>   >> few fields.
>   >>   >> 
>   >>   >> The subselect only produces one column; so I think that the
>   >>   >> error message is wrong.
>   >>   >
>   >>   >What is the GROUP BY doing?
>  
> ...
> 
>   >Maybe I should be clearer.  You are grouping by a column that is not in
>   >the target list.  If you try the subquery on its own, it should fail
>   >with a better error message.
>  
> It doesn't fail; it produces the results I want.
> 
>   bray=> select min(rcrelid) from pg_relcheck group by rcname;
>      min
>   ------
>   115940
>   115026
>   115026
>   115026
>   ... etc ...
> 
> Any way, why should it be an error to group by a column that is not in the
> results list, if the results list comprises aggregates only?
> 
> (Mind you, I think I have not yet got a reliable way of finding the
> ultimate ancestor of an inherited constraint.  Is it actually possible to
> do this with queries or do we have to add a boolean flag to pg_relcheck
> to be set where the constraint is/is not inherited?)

Gee, I didn't know we could do that.  Seems like doing that in a
subquery messes things up.  My guess is that the GROUP BY internally
carries the GROUP BY column, and that is not getting stripped when used
in a subquery, so it thinks the subquery returns two columns.  Perhaps
the junknode code needs to be added somewhere for subqueries?

Can anyone else comment on this possibility?


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026