| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Fabrizio Mello <fabriziomello(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Store Extension Options |
| Date: | 2014-01-04 19:09:29 |
| Message-ID: | 20140104190929.GA18220@alap2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-01-04 14:06:19 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-01-04 13:00:03 -0500, Tom Lane wrote:
> >> Assuming that such examples are forthcoming, though, I think my main
> >> objection to this proposal is the "ext." prefix, which seems precisely
> >> 100% useless, not to mention inconsistent with the naming of custom GUCs,
> >> which the same extension might well have some of.
>
> > Well, the argument is/was that it avoid conflicts with future core code
> > adding more namespaces - like the already existing toast. prefix. If we
> > say we can live with the possibility of such conflicts, it seems
> > appropriate not to use ext. as a prefix.
>
> And if we have ext. as a prefix, exactly what prevents conflicts in the
> second part of the name? Nothing, that's what. It's useless.
Uh? We are certainly not going to add core code that defines relation
options with ext. in the name like we've introduced toast.fillfactor et
al?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-01-04 19:11:37 | Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL |
| Previous Message | Tom Lane | 2014-01-04 19:06:19 | Re: [PATCH] Store Extension Options |