On Wed, Oct 8, 2014 at 2:55 AM, David Fetter <da...@fetter.org> wrote:
>
> On Wed, Oct 08, 2014 at 12:41:46AM -0300, Fabrízio de Royes Mello wrote:
> > On Wed, Oct 8, 2014 at 12:36 AM, Josh Berkus <j...@agliodbs.com> wrote:
> > >
> > > On 10/07/2014 09:44 AM, Fabrízio de Royes Mello wrote:
> > > > We can think in a mechanism to create "properties / options" and
assign
> > it
> > > > to objects (table, index, column, schema, ...) like COMMENT does.
> > > >
> > > > A quickly thought:
> > > >
> > > > CREATE OPTION [ IF NOT EXISTS ] name
> > > > VALIDATOR valfunction
> > > > [ DEFAULT value ];
> > > >
> > > > ALTER TABLE name
> > > > SET OPTION optname { TO | = } { value | 'value' | DEFAULT };
> > > >
> > > > It's just a simple thought of course. We must think better about the
> > syntax
> > > > and purposes.
> > >
> > > If we're going to do this (and it seems like a good idea), we really,
> > > really, really need to include some general system views which expose
> > > the options in a user-friendly format (like columns, JSON or an
array).
> > > It's already very hard for users to get information about what
> > > reloptions have been set.
> > >
> >
> > Maybe into "information_schema" ??
>
> Not there. The information schema is defined pretty precisely in the
> SQL standard and contains only some of this kind of information.
>
You're absolutely right.. thanks...
> pg_catalog seems like a much more appropriate space for
> PostgreSQL-specific settings.
>
We can add views and some functions to get this info too.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello
