From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Fabrízio Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Erik Rijkers <er(at)xs4all(dot)nl>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bug? import foreign schema forgets to import column description |
Date: | 2018-01-05 01:45:37 |
Message-ID: | CAB7nPqSgs0Zx4RSe7fHjvAcaw+uWx9nt3GYF_7tt8pR+F_si=g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 5, 2018 at 4:42 AM, Fabrízio de Royes Mello
<fabriziomello(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-01-05 02:00:48 | Re: [HACKERS] Runtime Partition Pruning |
Previous Message | Michael Paquier | 2018-01-05 01:26:37 | Re: BUG #14999: pg_rewind corrupts control file global/pg_control |