| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Fabrízio Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Store Extension Options |
| Date: | 2014-01-03 00:16:55 |
| Message-ID: | CA+TgmoYz7eT5tO+aWUpyS27HQFNLd0F661_RiZGR0QDWOVeVWw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 2, 2014 at 4:19 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-12-31 13:37:59 +0100, Pavel Stehule wrote:
>> > We use the namespace "ext" to the internal code
>> > (src/backend/access/common/reloptions.c) skip some validations and store
>> > the custom GUC.
>> >
>> > Do you think we don't need to use the "ext" namespace?
>> >
>>
>> yes - there be same mechanism as we use for GUC
>
> There is no existing mechanism to handle conflicts for GUCs. The
> difference is that for GUCs nearly no "namespaced" GUCs exist (plperl,
> plpgsql have some), but postgres defines at least autovacuum. and
> toast. namespaces for relation options.
I continue to think that the case for having this feature at all has
not been well-made.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-01-03 00:21:03 | Re: fix_PGSTAT_NUM_TABENTRIES_macro patch |
| Previous Message | Peter Geoghegan | 2014-01-02 23:56:22 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |