On Mon, Sep 23, 2013 at 9:36 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> I think the idea that we should consider a different way of handling
> tabular configuration data has merit. In fact, how much sense does it
> make to have these options (the ones for which this patch is being
> written) be GUCs in the first place? ALTER USER/DATABASE don't work for
> them, they can't be usefully changed in the commandline, there's no
> working SET.
>
> If we had some way to plug these into pg_hba.conf parsing machinery
> (which is tabular data), I would suggest that. But that doesn't sound
> really sensible. I think the idea of putting this configuratio data
> in a separate file, and perhaps a more convenient format than
> three-level GUC options, should be considered.
All very good points, IMHO. In a lot of cases, what you want is
sneazle.list='foo,bar'
sneazle.foo.prop1='zatz'
sneazle.bar.prop1='frotz'
etc.
But that means that the set of GUCs that exist to be SET needs to
change every time sneazle.list changes, and we haven't got any good
mechanism for that. I really think we're trying to squeeze a square
peg into a round hole here, and I accordingly propose to mark this
patch rejected.
It seems to me that if an extension wants to read and parse a
configuration file in $PGDATA, it doesn't need any special core
support for that. If there's enough consistency in terms of what
those configuration files look like across various extensions, we
might choose to provide a set of common tools in core to help parse
them. But I'm not too convinced any useful pattern will emerge.
Another option is to store the data in an actual table. One could
have sneazle.configtable='dbname.schemaname.tablename', for example.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company