Re: patch: SQL/MED(FDW) DDL - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: patch: SQL/MED(FDW) DDL
Date
Msg-id AANLkTi=dXAzCm8+R03gzkCd_8FJ+9njW_Gj6wHujx3r9@mail.gmail.com
Whole thread Raw
In response to Re: patch: SQL/MED(FDW) DDL  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: patch: SQL/MED(FDW) DDL  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Wed, Sep 29, 2010 at 11:09 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> I'm not sure that it's a good idea to embed into the FDW API the set of
> operations known to the executor.  For example your proposal fails to
> consider bitmap scans.  Seems simpler and more general to hand the quals
> over saying "I need to scan this relation with these quals", and have it
> return an opaque iterable object;

Agreed. If possible, we will avoid dedicated interfaces for seqscans and
index scans. However, bitmap scan is difficult anyway because foreign tables
might not have ctid columns. It's a challenging task to identify individual
tuples in foreign tables. It will be also used for UPDATE and DELETE.

> There doesn't to be much point in knowing the names of remote indexes
> either (if it came to referencing them, better use OIDs)

FYI, HiRDB, that implements FDW routines, has CREATE FOREIGN INDEX.
I think it is a little ugly and won't work in some cases -- for example,
index organized tables -- but evidently it's a realistic solution.

--
Itagaki Takahiro


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: security hook on table creation
Next
From: KaiGai Kohei
Date:
Subject: Re: security hook on table creation