Re: bug? import foreign schema forgets to import column description

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: bug? import foreign schema forgets to import column description
Дата
Msg-id CAB7nPqSgs0Zx4RSe7fHjvAcaw+uWx9nt3GYF_7tt8pR+F_si=g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: bug? import foreign schema forgets to import column description  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Список pgsql-hackers
On Fri, Jan 5, 2018 at 4:42 AM, Fabrízio de Royes Mello
<fabriziomello@gmail.com> wrote:
> There are some impediment to don't import Comments from foreign objects?

The only thing at SQL level which I know of able to copy comments from
another table is LIKE COMMENTS. For IMPORT FOREIGN SCHEMA, we assume
that FDWs only send back a list of strings that can be parsed as
CreateForeignTableStmt. Relying on this strict rule makes the code
more robust at the end. We don't want more object types like
CommentStmt and such. Does the SQL standard specifies a way to have a
comment defined for a column or a relation directly within CREATE
FOREIGN TABLE. If yes, then it could make sense to have an option
within postgres_fdw, after of course adding handling for this query
extension.

Using HEAD, I can see one way to somewhat work around that by having
postgres_fdw pass an option string with the comment for the relation
and each column, but you would need some extra steps after the CREATE
FOREIGN TABLE runs as this code path execution is not dedicated to
postgres_fdw. But combined the utility hook you could actually make
something work. Now that's grotty, and a lot of work for a small gain.
--
Michael


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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] path toward faster partition pruning
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning