FDWs, foreign servers and user mappings - Mailing list pgsql-general

From Joe Abbate
Subject FDWs, foreign servers and user mappings
Date
Msg-id 4F57D03F.2020706@freedomcircle.com
Whole thread Raw
Responses Re: FDWs, foreign servers and user mappings
List pgsql-general
Hi,

We've been discussing the subject in the pyrseas-general ML, but I think
it would be beneficial to get feedback from a broader audience.

The Pyrseas dbtoyaml utility outputs the objects in YAML, which ends up
looking like a tree (see
http://pyrseas.readthedocs.org/en/latest/dbtoyaml.html ) and similar to
the tree in pgAdmin's Object Browser panel.

Any object that is owned by a schema (tables, functions, etc.) is listed
naturally under the schema.  The objects (columns, constraints, etc.)
that belong to a table are listed under the table, and so forth.  Only a
few object types fall outside the "schema tree," e.g., casts, languages
(extensions, collations in 9.1).

Because FDW's, foreign servers and user mappings are not directly tied
to a schema and their identifiers must be unique within a given
database, I first added them at the top level, e.g.,

foreign data wrapper fdw1:
  ...
schema public:
  ...
server fs1:
  wrapper: fdw1
user mapping for PUBLIC server fs1:
  options:
  - xxx=yyy

A Pyrseas user suggested that servers ought to be listed under the
associated FDW, e.g.,

foreign data wrapper fdw1:
  server fs1:
  ...

The question is whether user mappings should also be listed under the
server, i.e.,

foreign data wrapper fdw1:
  server fs1:
    user mapping for PUBLIC:
      options:
      - xxx=yyy

Does that make sense?  And if so, will it make sense in the future
(considering potential FDW developments)?

A related question was whether user mapping options, which may include
sensitive data such as passwords, should be output by default.  I'm not
sure if this should extend to other FDW-related options, since a server
option could presumably be a URI that includes logon information.

Thanks in advance.

Joe

pgsql-general by date:

Previous
From: pawel_kukawski
Date:
Subject: autovacuum and transaction id wraparound
Next
From: Aleksey Tsalolikhin
Date:
Subject: Re: phantom long-running query (check_postgres.pl reports a long-running query, but the database logs don't show it)