* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > This, plus the generic ability to pass an OPTIONS clause to the IMPORT > > (allowing you to have different defaults for different IMPORT > > statements) and having it be transactional, as you mention, appears to > > be covering all the relevant bases. > > Yeah, as far as the example of coping with differing case goes, I agree > that we'd want IMPORT to just follow whatever the FDW's default or > configured behavior is, since obviously the FDW will have to know how to > reverse the conversion when sending queries later on. So there's no > apparent need for an IMPORT-level option *for that example*. I'm not > sure if we need OPTIONS for IMPORT for any other uses.
I'm waffling a bit on this particular point. IMPORT is for bulk operations, of course, but perhaps on one remote server you want to import everything from the dimension tables using the default mapping but everything from the fact or perhaps aggregate tables in some schema as text. You could do that with something like- import #1, change the server-level options, import #2, or you could do just one big import and then go back and fix everything, but... I'd rather introduce this options clause for IMPORT *now*, which means we don't need to care about if this specific example is really relevant or not, than not have it in 9.5 and have FDW authors unhappy because it's missing (whether they need it for this use case or some other). Thanks, Stephen
Description: Digital signature