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
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 |