Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
PostgreSQL 9.5 IMPORT FOREIGN SCHEMA #10
This is not a bug, but a feature request.
I've started playing around with this. It's not that much work I don't think. A lot of the logic @pramsey has in ogrfdw_info can be repurposed for this and I've already cut in the IMPORT FOREIGN schema glue I saw in the postgresql_fdw code.
One thing I'm not sure how to handle is IMPORT FOREIGN SCHEMA <remote_schema>
the remote_schema is a required bit. There are two ways that come to mind to handle this:
For schema checking I was going to assume that databases that have schema's the tables come thru via with dot's
For example when I connect to SQL Server, table names come down as
etc. but not sure if that is a true statement for all/most OGR data sources or if there is a logic in OGR to handle schemas. I don't think there is.
The other minor issue is handling EXCEPT and LIMIT TO clauses in IMPORT FOREIGN SCHEMA.
One benefit about using a specific schema word to mean ignore schemas, is that if a true schema name is used, then we know the EXCEPT / LIMIT TO need not include the schema name (or it has to be fully qualified in case of all).
Okay getting warm now, I have successfully imported a table with import foreign schema. Now to work out some kinks.
It does seem that there is a mechanism for options:
So for first option, I wanted to define a launder column names option. If that is not set to true, then the column names would come in exactly as they are in remote data source, instead of being forced to lower case and having unsavory names changed. Not sure if the launder should apply to table name as well (minus the schema part) or if we should have a separate option for that.
-- UPDATE -- this is sweet
Just generated 101 foreign tables from an access database and without having my columns and table names laundered - in 861 msecs.
Okay I decided to go with two separate laundering options and default both to true if not specified.
So I have:
So to use for example I have a statements like this:
Since I set it to false, the casing and weird junk in my table names are preserved.
Similarly if I do this:
Both table and column name casing and weird characters are preserved. Now all I have left is to tackle the EXCEPT / LIMIT TO and do something with the remote schema and I think my patch (when I submit it - after @pramsey has committed my 9.5rc1 fix patch) will be feature complete :).
I was mistaken about schema - I was trying to use all for remote schema, and that's a reserved word. So user-error on that one.
For remote schema functionality, I decided to go with using the remote_schema as a prefix instead of as a real schema. Reason is things like WFS could have very nested names with periods and the concept then also becomes useful for things that don't have schemas.
For the ignore schema option, I decided to go with name ogr_all for remote schema name.
So for example:
Tested it out and works nicely.
Okay the EXCEPT / LIMIT TO I confirmed from Tom Lane is handled by the post processor, and it does filter out CREATE FOREIGN TABLE statements that are in violation of the LIMIT TO / EXCEPT.
So that explains when I set launder_table_names 'false' it worked as expected. The whole driver specific thing was more to do with the funkiness of names.
I think we should still direclty handle LIMIT/EXCEPT ourselves first (like postgres_fdw does) just because depending on datasource, getting the whole table definition might be expensive.
I changed the logic I had and the readme to reflect that the LIMIT TO / EXCEPT should NOT use the layer names (unless table name laundering is off), but should use post laundered names. That does mean users have to have an idea how the laundering works though.