[ https://issues.redhat.com/browse/TEIIDSB-206?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIIDSB-206: ---------------------------------------- They are all virtual file sources, but obviously hit different things. I know we talked about this in the past, but I deferred on a strategy. To explain this more, what we currently have: CREATE SERVER x1 FOREIGN DATA WRAPPER file; -- currently means file source with a file translator CREATE SERVER x2 FOREIGN DATA WRAPPER excel; -- currently means file source with an excel translator CREATE SERVER x3 FOREIGN DATA WRAPPER ftp; -- currently means an ftp source with an ftp translator, which is a bug because there is no ftp translator What has just been added: CREATE SERVER x1 FOREIGN DATA WRAPPER hdfs; -- currently means an ftp source with an ftp translator, which is a bug because there is no hdfs translator So obviously the last two need to point to file translator instead. But the real issue is that this approach is baking in a single translator for a given source name. excel can work against file, ftp, hdfs, and s3 once it's added. The rationale for doing the hdfs and s3 work first was actually so that avro and parquet support would make sense at a translator level. Option 1: use the create server type information. You can default an alias to a given translator, but also specify it: CREATE SERVER x2 FOREIGN DATA WRAPPER excel could be fully expressed as: CREATE SERVER x2 TYPE file FOREIGN DATA WRAPPER excel and would allow for the other combinations: CREATE SERVER x2 TYPE hdfs FOREIGN DATA WRAPPER excel The only downside is explicitly introducing the source type construct. Option 2: explicit and verbose expansion of alias names / connection factories. create excel-file, excel-ftp, excel-hdfs, avro-hdfs, etc. Option 3: assume some kind of convention in the foreign data wrapper name. -- This message was sent by Atlassian Jira (v7.13.8#713008)