Re: SQL/MED estimated time of arrival?

On Sun, 21 Nov 2010 21:16:05 -0500
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
<snip>
> Ultimately, we probably want and need to get this patch down to chunks
> of less than 2000 lines each. But for starters, it looks quite simple
> to break this into three chunks: one for the PostgreSQL FDW, one for
> the CSV FDW, and one for the core functionality. I think that the CSV
> FDW, like the PG FDW, should be a loadable module.

I've separated the patch into tree parts. They have codes, documents
and tests within, and file_fdw and pgsql_fdw can be applied onto
fdw_core for each, or together. I hope the separation helps the
review of the patches. Contents of each patch are:

fdw_core : DDL for FDW HANDLER and FOREIGN TABLE, ForeignScan
file_fdw : FDW for file, as contrib (loadable) module
pgsql_fdw: FDW for PG, as contrib module

The fdw_core patch is still very large (it has 10336 lines), but about
the half of the patch is unchanged lines. The brief of lines actually
changed are:

backend codes : 3000
regression tests : 500
sgml documents : 1500

Basic functionality is not changed, but when I separate file_fdw from
core, I relaxed the requirement that FDW must have HANDLER to create
FOREIGN TABLE. Now FDW is required to have valid Iterate function
only when scanning (or EXPLAINing) the foreign table actually. It
enables testing DDLs for FOREIGN TABLE with HANDLER-less-FDW.

> (I wonder if it
> would be more sensible to name all the FDWs as "fdw_foo" rather than
> "foo_fdw", so that they alphabetize together, but I believe that Tom
> has shot down similar suggestions in the past, so maybe it's not a
> good idea after all.)

I agree the naming you suggested, but it would need to change the name
of existing function postgresql_fdw_validator to keep consistency. I
couldn't find any discussion about the naming of fdw.

Regards,
--
Shigeru Hanada