Re: IMPORT FOREIGN SCHEMA statement

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-05-27 14:29:44
Message-ID: 20140527142944.GK2556@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> Stephen Frost wrote:
> > > 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.
> >
> > The oracle FDW would simply need a foreign-server level option which
> > says "smash everything to lowercase on import".
>
> That's not the same thing though -- consider what happens to the quoting
> needs for names with mixed case. If you change mixed case to
> all-lowercase, references to such objects using quotes in the
> application code would fail because the name is now all-lowercase in
> Postgres. A tri-valued enum could do the trick:
> lowercase_names={wholly_uppercase_only, all, none}
> with the first one being the most sensible and default.

Sure, I was being a bit over-simplistic. As was mentioned up-thread,
the option would rather be "flip all-uppercase to lowercase and all-
lowercase to uppercase, quote any which are mixed", or something along
those lines. What I was trying to get at is that it's up to the FDW
what options it wants to support in this regard and we already have a
way for the admin to pass in useful information to the FDW by way of the
FOREIGN SERVER FDW options.

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.

Thanks,

stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matteo Beccati 2014-05-27 14:36:45 Re: [PATCH] Replacement for OSSP-UUID for Linux and BSD
Previous Message Alvaro Herrera 2014-05-27 14:23:57 Re: IMPORT FOREIGN SCHEMA statement