On Sat, Jan 4, 2014 at 11:07 AM, Fabrizio Mello <fabriziome...@gmail.com> wrote: >> I continue to think that the case for having this feature at all has >> not been well-made. > > We can use this feature to store any custom GUC for relations, attributes and > functions also. > > Some use cases: > * extension options > * config for external apps (frameworks, third part software) > > Comments?
Well, as I said before, somebody can make their own configuration table and store stuff there, rather than using pg_class.reloptions. As I recall, the only response to that proposal was "well, they might not want to do it that way", which does not strike me as a sufficient reason. What we've basically settled into for GUCs is that you can register a custom GUC, but unless the module is loaded we'll accept any value for that GUC without checking it. We'd presumably need a similar mechanism here, or maybe you're proposing that we accept any reloption at all with any associated value whatsoever, so long as the prefix is ext. The first seems like an extension of an existing kludge of which I'm not overly found, and the second is an even larger kludge. In my experience as a software developer, there are very few places where it's useful to accept and store user input without any validation whatsoever, and I doubt that this is one of them. -- 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
