Re: BUG #12465: Materialized view dump restoration issue

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: BUG #12465: Materialized view dump restoration issue
Дата
Msg-id
12297.1420836142@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
BUG #12465: Materialized view dump restoration issue jeff.casavant@gmail.com
Re: BUG #12465: Materialized view dump restoration issue Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #12465: Materialized view dump restoration issue Marko Tiikkaja <marko@joh.to>
Re: BUG #12465: Materialized view dump restoration issue Tom Lane <tgl@sss.pgh.pa.us>
Re: BUG #12465: Materialized view dump restoration issue Marko Tiikkaja <marko@joh.to>
Re: BUG #12465: Materialized view dump restoration issue Jefferson Casavant <jeff.casavant@gmail.com>
PQLIB: Prepared statement speed oddity Mark Simonetti <marks@opalsoftware.co.uk>
Re: PQLIB: Prepared statement speed oddity Mark Simonetti <marks@opalsoftware.co.uk>
jeff.casavant@gmail.com writes:
> Code to reproduce:

> create function b() returns int as $$ select 1 $$ language sql;
> create function a() returns int as $$ select b() $$ language sql;
> create schema qwr;
> create materialized view qwr.c as select a();

This is not a pg_dump bug, this is a broken definition of function a().
That function will fail in any context where the caller changes
search_path, not only pg_dump.  You can perhaps get away without that
in a single-schema database, but not with multiple schemas.

You could fix it by schema-qualifying b in the text of a,
or by adding a "SET schema_path" clause to a.

			regards, tom lane
В списке pgsql-bugs по дате отправления
От: Kevin Grittner
Дата:
От: Marko Tiikkaja
Дата:
FAQ