On Thu, 2008-07-24 at 10:30 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> 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.comPostgreSQL Training, Services and Support
