* 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
signature.asc
Description: Digital signature
