Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables) |
| Дата | |
| Msg-id | 4309.1363053848@sss.pgh.pa.us обсуждение |
| Ответ на | Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3] writable foreign tables) (Daniel Farina <daniel@heroku.com>) |
| Ответы |
Re: postgres_fdw vs data formatting GUCs (was Re: [v9.3]
writable foreign tables)
|
| Список | pgsql-hackers |
Daniel Farina <daniel@heroku.com> writes:
> I will try to make time for this, although it seems like the general
> approach should match pgsql_fdw if possible. Is the current thinking
> to forward the settings and then use the GUC hooks to track updates?
That's not what I had in mind for postgres_fdw --- rather the idea is to
avoid needing on-the-fly changes in remote-side settings, because those
are so expensive to make. However, postgres_fdw is fortunate in that
the SQL it expects to execute on the remote side is very constrained.
dblink might need a different solution that would leave room for
user-driven changes of remote-side settings.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера