Re: Uncopied parameters on CREATE TABLE LIKE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Uncopied parameters on CREATE TABLE LIKE
Date: 2008-07-24 14:30:28
Message-ID: 29609.1216909828@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)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. 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-07-24 15:11:24 Re: Uncopied parameters on CREATE TABLE LIKE
Previous Message Hannu Krosing 2008-07-24 14:25:35 Re: Do we really want to migrate plproxy and citext into PG core distribution?