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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026