Re: per-column generic option

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

(2011/07/12 0:44), Peter Eisentraut wrote:
> On lör, 2011-07-09 at 23:49 -0400, Alvaro Herrera wrote:
>> The new ALTER TABLE grammar seems a bit strange -- ADD, SET, DROP. Is
>> this defined by the SQL/MED standard? It seems at odds with our
>> handling of attoptions
>
> Well, I believe the SQL/MED options were actually implemented first and
> the attoptions afterwards. But it's probably not unwise to keep them
> separate, even though the syntaxes could have been made more similar.

As you say, syntax for attoptions/reloptions seem to satisfy the
requirement of SQL/MED; SET for ADD/SET and RESET for DROP.

But at this time it would break backward compatibility. I think it's
reasonable to unify the syntax for handling SQL/MED options at every
level to "OPTIONS (key 'value', ...)".

Regards,
--
Shigeru Hanada

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2011-07-12 07:12:31 Re: make_greater_string() does not return a string in some cases
Previous Message Alexander Korotkov 2011-07-12 07:05:53 Re: WIP: Fast GiST index build