Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view
От | Daniel Cristian Cruz |
---|---|
Тема | Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view |
Дата | |
Msg-id | BANLkTika92geQx5rfaAqhs2PvSMMdkg+oQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-bugs |
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 <robertmhaas@gmail.com> > On Fri, Jun 3, 2011 at 2:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane <tgl@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 > --=20 Daniel Cristian Cruz =E3=82=AF=E3=83=AB=E3=82=BA =E3=82=AF=E3=83=AA=E3=82=B9=E3=83=81=E3=82=A2= =E3=83=B3 =E3=83=80=E3=83=8B=E3=82=A8=E3=83=AB
В списке pgsql-bugs по дате отправления: