From: | NikhilS <nikkhils(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Gaetano Mendola" <mendola(at)bigfoot(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: UPDATE using sub selects |
Date: | 2007-03-16 14:55:16 |
Message-ID: | d3c4af540703160755y32f9cbc4we8f0b34aa98a141e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 3/16/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> NikhilS <nikkhils(at)gmail(dot)com> writes:
> > To allow both of the above to hold, I think the subselect will have to
> be
> > treated like a EXPR_SUBLINK subquery. I was wondering if we have a
> similar
> > mechanism for plain selects/subselects to check and restrict their
> output to
> > a single row.
>
> No. Offhand I think you'd either need to relax EXPR_SUBLINK to allow
> multiple output columns, or invent a ROW_SUBLINK SubLinkType that is
> just like EXPR_SUBLINK except for allowing multiple output columns.
> The latter would probably be less likely to break other things...
Yeah, was looking at EXPR_SUBLINK and its single column use case and drove
to the same conclusion that inventing a new sublink type would be better
too. It is indeed becoming a "not so simple and narrow fix" as you had
mentioned earlier in your first response :)
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2007-03-16 15:01:09 | Re: tsearch_core for inclusion |
Previous Message | Tom Lane | 2007-03-16 14:54:45 | Re: Lock table in non-volatile functions |