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. What is the real use-case for
this bit of complication? 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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
