Re: Uncopied parameters on CREATE TABLE LIKE
От | Simon Riggs |
---|---|
Тема | Re: Uncopied parameters on CREATE TABLE LIKE |
Дата | |
Msg-id | 1216912284.3894.841.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Uncopied parameters on CREATE TABLE LIKE (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Uncopied parameters on CREATE TABLE LIKE
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: