On Wed, Oct 8, 2014 at 2:55 AM, David Fetter <david@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 <josh@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.
