Re: Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view
От | Tom Lane |
---|---|
Тема | Re: Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view |
Дата | |
Msg-id | 12928.1307457185@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view (Greg Stark <gsstark@gmail.com>) |
Ответы |
Re: Re: BUG #6050: Dump and restore of view after a schema
change: can't restore the view
|
Список | pgsql-bugs |
Greg Stark <gsstark@gmail.com> writes: > On Jun 3, 2011 4:20 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: >> I'm inclined to write this off as "so don't do that". There's nothing >> that pg_dump can do to make this work: it has to use the USING syntax >> for the join, and that doesn't offer any way to qualify the column name >> on just one side. > There's nothing stopping us from adding a nonstandard syntax to cover > precisely the information needed to resolve this case when dumping. > For example we could support USING (a.a=b.a) or ON (a.a=b.a as a) 1. "Nonstandard syntax" is widely seen as "vendor lock-in". I don't think that people would appreciate such a fix, especially for an issue so obscure that we've never seen it before. 2. I don't believe your proposal covers all cases. For instance, there are cases where there is no valid qualified name for a column, ie, it's a merged column from an alias-less JOIN. (The existence of such cases is another reason why USING sucks, but I digress.) > We could use it only in this case where there's ambiguity too so it wouldn't > clutter people's dumps. No, because the problem case is where ambiguity gets added after the fact. regards, tom lane
В списке pgsql-bugs по дате отправления: