Re: SQL/MED - core functionality

From: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED - core functionality
Date: 2010-12-14 14:06:21
Message-ID: 20101214230620.A5F8.6989961C@metrosystems.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 13 Dec 2010 21:51:40 -0500
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> This actually doesn't apply cleanly. There's a hunk in pg_class.h
> that is failing.

I might have missed recent changes about pg_class.relistemp.
I've fixed in local repo.

> I think attgenoptions is a poor choice of name for the concept it
> represents. Surely it should be attfdwoptions. But I am wondering
> whether we could actually go a step further and break this
> functionality off into a separate patch. Do file_fdw and/or
> postgresql_fdw require column-level FDW options? If not, splitting
> this part out looks like it would be a fairly significant
> simplification for v1

In current FDW implementation, column-level FDW options are used as:

1) force_not_null option of file_fdw. COPY FROM accepts the option as
column name list, but it would be complicated to accept it in
table-level FDW option.

2) column name alias option in postgresql_fdw.

But they don't seem necessary to discuss basic design.

> Along similar lines, I think we could simplify the first version of
> this considerably by removing all the support for constraints on
> foreign tables. It might be useful to have that some day, but in the
> interest of whittling this down to a manageable size, it seems like we
> could easily do without that for starters.
>
> On the other hand, I don't really see any advantage to allowing rules
> on foreign tables - ever. Unless there's some reason we really need
> that, my gut feeling would be to rip it out and forget about it.
>
> The docs should avoid cut-and-pasting large quantities of the existing
> docs. Instead, they should refer to the existing material.

CHECK constraint allowed to support constraint exclusion, but NOT NULL
is designed for just query-time constraint.

I'll simplify the patch and post patches 1-4 of below first.

<essential part>
1) Basic syntax for FOREIGN TABLE and FDW HANDLER
2) FDW API and ForeignScan execution
# These patches are split just to make review easy.

<FDW implementation>
3) pgsql_fdw
4) file_fdw

<Additional features>
5) NOT NULL constraint and query-time evaluation
6) column-level FDW option
- syntax and catalog
- column alias option for pgsql_fdw
- force_not_null option for file_fdw
7) RULE

> Copyright notice for new files should go through 2010, not 2009.

Will be fixed in next patch.
I also replaced all $PostgreSQL$ with actual file names.

Regards,
--
Shigeru Hanada

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2010-12-14 14:19:32 Re: Transaction-scope advisory locks
Previous Message Robert Haas 2010-12-14 14:01:12 Re: CommitFest wrap-up