bug? import foreign schema forgets to import column description
Hi all,
Using IMPORT FOREIGN SCHEMA I notice that the column descriptions of
the remote tables are not taken along to the imported schema. I am
usgin postgres_fdw to 'import' a schema with foreign tables (but the
same omission happens with ordinary tables as well).
This is a bug, no? Surely the description strings should be available
at the receiving end.
Do you agree this is an oversight that should be fixed?
thanks,
Erik Rijkers
Erik Rijkers <er@xs4all.nl> writes:
Using IMPORT FOREIGN SCHEMA I notice that the column descriptions of
the remote tables are not taken along to the imported schema.
Comments, you mean?
Do you agree this is an oversight that should be fixed?
Not particularly. It certainly isn't a bug.
regards, tom lane
On Thu, Jan 4, 2018 at 5:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Erik Rijkers <er@xs4all.nl> writes:
Using IMPORT FOREIGN SCHEMA I notice that the column descriptions of
the remote tables are not taken along to the imported schema.Comments, you mean?
Do you agree this is an oversight that should be fixed?
Not particularly. It certainly isn't a bug.
There are some impediment to don't import Comments from foreign objects?
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Show quoted text
Timbira: http://www.timbira.com.br
Blog: http://fabriziomello.github.io
Linkedin: http://br.linkedin.com/in/fabriziomello
Twitter: http://twitter.com/fabriziomello
Github: http://github.com/fabriziomello
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