Skip site navigation (1) Skip section navigation (2)

Re: UPDATE using sub selects

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-30 11:26:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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 :)

I have invented a ROWEXPR_SUBLINK type that handles multiple output columns.
The trouble is that since eventually columns of the parents have to be part
of the query's targetList, I am sending the entire subquery as one of the
entries in that list and the targetList gets populated with entries
dependent on the subquery much later via make_subplan.

This breaks code in rewriteTargetList (which expects every list entry to be
of type TargetEntry), and expand_targetlist (which expects the targets to be
present in attrno order, the entries added because of the subquery will not
be in order as compared to normal "SET colname = expr" targets).

Is there a simpler way of doing things? Should I try generating a resjunk
TargetEntry in transformUpdateStmt and have its expr point to the subquery
and see if that works?


In response to


pgsql-hackers by date

Next:From: Richard HuxtonDate: 2007-03-30 11:48:47
Subject: Re: [PATCHES] Full page writes improvement, code update
Previous:From: Simon RiggsDate: 2007-03-30 11:21:29
Subject: Re: [PATCHES] Full page writes improvement, code update

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group