On 2014-01-04 11:54:46 -0500, Robert Haas wrote: > 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.
Well, there's some things you get by that integration: * Proper dependency tracking when relations are dropped & renamed * Sensible integration into pg_dump, with only the relevant options being dumped/restored on partial dump/restores * Caching of values, with proper cache invalidation Sure, you can implement both using event triggers and relcache invalidation callbacks, but that's not something we want several extensions to do independently. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
