On Mon, Sep 23, 2013 at 9:36 AM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
