But as a PostgreSQL user, I would like to had a warning when creating a view with USING. It solves my problem. Maybe many others too.
2011/6/7 Robert Haas <robertmh...@gmail.com> > On Fri, Jun 3, 2011 at 2:21 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> Now, if the query doesn't involve any explicit reference to > "joinalias.*", > >>> we could probably fake it with some ugly thing involving > >>> COALESCE(leftcol, rightcol) ... but I don't think people will want to > >>> read that, and anyway the idea falls apart as soon as you do have a > >>> whole-row reference. > > > >> Well, it gets internally translated to COALESCE(leftcol, rightcol) > > > > We do that during planning; it's not the form that gets stored in views > > or dumped by pg_dump. I don't really want pg_dump dumping this kind of > > thing, because that locks us down to supporting it that way forever. > > Hmm. > > >> I'm not seeing the problem with whole-row references; can you elaborate > on that? > > > > SELECT somefunc(j.*) FROM (tab1 JOIN tab2 USING (id)) j; > > > > The shape of the record passed to somefunc() depends on removal of the > > second id column. > > Ah, yes. > > > Now you might claim that we could expand the j.* to a ROW() construct > > with an explicit list of columns, which indeed is what happens > > internally. But again, that happens at plan time, it's not what gets > > stored in rules. And that matters, because locking down the column > > expansion too early would break the response to ADD/DROP COLUMN on > > one of the input tables. > > Fair enough, but the current implementation with respect to ADD > COLUMN. And RENAME COLUMN. > > If your point here is that you don't want to spend time hacking on > this because it's a fairly marginal feature and therefore not terribly > high on your priority list, I can understand that. But if you're > actually defending the current implementation, I'm going to have to > respectfully disagree. It's broken, and it sucks, and this is not the > first complaint we've had about it. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Daniel Cristian Cruz クルズ クリスチアン ダニエル
