Re: IMPORT FOREIGN SCHEMA statement

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "Ronan Dunklau *EXTERN*" <ronan(dot)dunklau(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: IMPORT FOREIGN SCHEMA statement
Date: 2014-07-07 11:58:33
Message-ID: CA+TgmobuXG2YTmEQdFtZ=60dNBhbNnRsN_7OV2KACdQ5pNxJKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 26, 2014 at 12:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> writes:
>> In addition to data type mapping questions (which David already raised)
>> I have one problem when I think of the Oracle FDW:
>
>> Oracle follows the SQL standard in folding table names to upper case.
>> So this would normally result in a lot of PostgreSQL foreign tables
>> with upper case names, which would be odd and unpleasant.
>
>> I cannot see a way out of that, but I thought I should mention it.
>
> It seems like it would often be desirable for the Oracle FDW to smash
> all-upper-case names to all-lower-case while importing, so that no quoting
> is needed on either side. I doubt though that this is so desirable that
> it should happen unconditionally.
>
> Between this and the type-mapping questions, it seems likely that
> we're going to need a way for IMPORT FOREIGN SCHEMA to accept
> user-supplied control options, which would in general be specific
> to the FDW being used. (Another thing the SQL committee failed to
> think about.)

Is this part of the SQL standard? What is it defined to do about
non-table objects?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ronan Dunklau 2014-07-07 12:00:27 Re: IMPORT FOREIGN SCHEMA statement
Previous Message David Rowley 2014-07-07 11:56:42 Re: Allowing join removals for more join types