On Thu, 2008-07-24 at 10:30 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > I would prefer it if you had a plan to introduce user definable > > parameters, similar to custom_variable_classes. Perhaps call this > > "custom_table_options". So when we load a table and it has an option we > > don't recognise we ignore it if it is one of the customer_table_options. > > > custom_table_options will help us define special behaviours for > > datatypes, indexes, replication etc that relate to the specific role and > > purpose of individual tables. > > GUC parameters that silently alter the semantics of SQL statements > should be introduced only with great trepidation, not just because > someone thought them up one day.
I agree. I don't really want to alter semantics. > What is the real use-case for > this bit of complication? Reloptions are additional performance options. > Given the very short list of supported > reloptions right now, why would you imagine that there will ever > be such a thing as installation-local reloptions? There's a ton of ways to introduce installation-local code, and we support custom_variable_classes to support that. We just need some additional flexibility at object level also. It's already possible via comments, so why not make it official? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
