Re: SQL-standard function body

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SQL-standard function body
Дата
Msg-id 494838.1593543098@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SQL-standard function body  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: SQL-standard function body  (Robert Haas <robertmhaas@gmail.com>)
Re: SQL-standard function body  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
I wrote:
> Replicating the creation-time search path will be a big headache for
> pg_dump, I bet.

On further thought, we probably don't have to.  Re-parsing the function
body the same way is exactly the same problem as re-parsing a view or
matview body the same way.  I don't want to claim that that's a 100%
solved problem, but I've heard few complaints in that area lately.

The point remains that exposing the function body's dependencies will
constrain restore order far more than we are accustomed to see.  It
might be possible to build examples that flat out can't be restored,
even granting that we teach pg_dump how to break dependency loops
by first creating the function with empty body and later redefining
it with the real body.  (Admittedly, if that's possible then you
likely could make it happen with views too.  But somehow it seems
more likely that people would create spaghetti dependencies for
functions than views.)

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: new heapcheck contrib module
Следующее
От: Andres Freund
Дата:
Сообщение: Re: track_planning causing performance regression