Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2010-12-14 14:19:32
Subject: Re: Transaction-scope advisory locks
Previous:From: Robert HaasDate: 2010-12-14 14:01:12
Subject: Re: CommitFest wrap-up

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group