Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view

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