On tis, 2011-11-08 at 21:49 +0000, Thom Brown wrote:
> I found the following error message misleading:
>
> test=# create table cows2 (LIKE cows);
> ERROR: inherited relation "cows" is not a table
> STATEMENT: create table cows2 (LIKE cows);
>
> I'm not trying to inherit a relation, I'm trying to base a table on
> it.
It's not only the error message that's misleading, but the whole code,
because the entire code for CREATE TABLE ... (LIKE ...) claims to do
"inheritance" based on an ancient understanding of the SQL standard. I
know this has confused me many times already, so I decided to clean this
up and rename all the internal parser structures, split up the
regression tests for real inheritance and CREATE TABLE LIKE, and adjust
the error messages. Patch attached.
> As it happens, "cows" is a foreign table, which *is* a table,
> just not a regular table. It might be useful to add support to clone
> foreign tables into regular tables, the use-case being that you may
> wish to import all the data locally into a table of the same
> structure.
This is easy to fix, and I mangled it into my big renaming patch, which
I shouldn't have. Anyway, one question that's perhaps worth discussing
is whether we should allow and disallow the various INCLUDING options
depending on the relation type. For example, views don't have indexes,
so should we disallow INCLUDING INDEXES or just assume they don't have
any?