Re: [PATCH] Store Extension Options

From: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Store Extension Options
Date: 2014-03-26 14:21:30
Message-ID: CAFcNs+p+2OA2fg7o-8KWmckazjAYWue6mVNnUdpuRpT0PZ8D_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 13, 2014 at 5:35 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> Well, I'm not sure that's really any big deal, but I'm not wedded to
> the label idea. My principal concern is: I'm opposed to allowing
> unvalidated options into the database. I think it should be a
> requirement that if the validator can't be found and called, then the
> reloption is no good and you just reject it. So, if we go with the
> reloptions route, I'd want to see pg_register_option_namespace go away
> in favor of some solution that preserves that property. One thing I
> kind of like about the LABEL approach is that it applies to virtually
> every object type, meaning that we might not have to repeat this
> discussion when (as seems inevitable) people want to be able to do
> things to schemas or tablespaces or roles. But I don't hold that
> position so strongly as to be unwilling to entertain any other
> options.
>

During the last days I thought about this discussion and to use SECLABELs
sounds weird to me. Here in Brazil we call this kind of thing 'gambiarra'.
Because we'll try to use something that born with a very well defined
purpose to another purpose. Personally I don't like that.

If we think more about SECLABELs, in a more abstract way, it is just a
'property' about database objects. And the same is COMMENTs. Both SECLABEL
and COMMENT provide a way to store something about objects.

Maybe we can think about a new object on top of COMMENT and SECLABELs. An
object called 'PROPERTY' or 'OPTION'. And COMMENTs and SECLABELs can be
just a kind of this new object, and we must introduce a new kind callled
'CUSTOM'.

I thought about this because representation (syntax) of SECLABELs and
COMMENTs are similar. They describe something about objects, they have
local and shared catalog.

This is just something that occurred to me. Maybe I'm completely wrong. Or
not!

Comments?

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-03-26 14:51:03 Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG
Previous Message Heikki Linnakangas 2014-03-26 12:08:28 Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG