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

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view
Дата
Msg-id BANLkTi=LjpFomFKwXUwkTbd5jUkJh52V6Q@mail.gmail.com
обсуждение исходный текст
Ответ на BUG #6050: Dump and restore of view after a schema change: can't restore the view  ("Daniel Cristian Cruz" <danielcristian@gmail.com>)
Ответы Re: Re: BUG #6050: Dump and restore of view after a schema change: can't restore the view  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Jun 3, 2011 4:20 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>
> > [ view definition now fails due to multiple "id_a" columns ]
>
> 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)

We could use it only in this case where there's ambiguity too so it wouldn't
clutter people's dumps.

That said it isn't very appetizing a change to backport so it doesn't do
much for the OP ...

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Anton Dedov
Дата:
Сообщение: ON DELETE CASCADE with multiple paths in PostgreSQL 9.x
Следующее
От: "Alex"
Дата:
Сообщение: BUG #6054: Insert to table, which has fkey to table,which is parenttable for another table - error