Re: per-column generic option

From: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: per-column generic option
Date: 2011-07-12 05:31:45
Message-ID: 4E1BDC41.30708@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2011/07/11 10:21), Robert Haas wrote:
> On Jul 9, 2011, at 10:49 PM, Alvaro Herrera<alvherre(at)commandprompt(dot)com> wrote:
>> In short: in my opinion, attoptions and attfdwoptions need to be one
>> thing and the same.
>
> I feel the opposite. In particular, what happens when a future release
> of PostgreSQL adds an attoption that happens to have the same name as
> somebody's per-column FDW option? Something breaks, that's what...
>
> Another point: We don't commingle these concepts at the table level.
> It doesn't make sense to have table reloptions separate from table FDW
> options but then go and make the opposite decision at the column
> level.

I'm afraid that I've misunderstood the discussion. Do you mean that
per-table options should be stored in reloptions, but per-column should
be separated from attoptions? (I think I've misread...)

Could you tell me little more detail why it doesn't make sense to have
table reloptions separate from table FDW options?

Regards,
--
Shigeru Hanada

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-07-12 07:05:48 Re: [HACKERS] Creating temp tables inside read only transactions
Previous Message Robert Haas 2011-07-12 03:43:22 Re: relpersistence and temp table