On Wednesday 17 December 2008 17:17:26 Martin Pihlak wrote:
> It'd make more sense if we changed the name to pg_get_datasource ;)
>
> We could make the pg_get_remote_connection_info Postgres specific -- in
> this case it would be changed to return just the connect string text. NULL
> for the other wrappers -- for these use the pg_get*options to construct
> the connect strings. Comments?
Well, what this function essentially does is a text transformation of the
options, something like this:
peter=# SELECT array_to_string(fdwoptions || srvoptions || umoptions, ' ')
FROM pg_foreign_data_wrapper fdw, pg_foreign_server srv, pg_user_mappings um
WHERE fdw.oid = srv.srvfdw AND srv.oid = um.srvid;
array_to_string
-----------------------------------------------------
host=localhost port=5432 user=peter password=seKret
(1 row)
(You can enhance this with quoting etc., but that's the essence.)
So, we could add a function whose job it is to convert all options to a
PostgreSQL connection string. I wouldn't worry about dealing with other
wrappers specifically. They could still use the function, but the result
would not make much sense.
I would call it something like
pg_postgresql_fdw_options_string(server, user) returns text
Not sure if a C implementation based on your old function or an SQL
implementation is better.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
