Re: Misleading CREATE TABLE error
Peter Eisentraut <peter_e@gmx.net>
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Thom Brown <thom@linux.com>, Robert Haas <robertmhaas@gmail.com>
Date: 2012-02-24T09:03:12Z
Lists: pgsql-hackers
Attachments
- create-table-like-composite-type.patch (text/x-patch) patch
On tis, 2011-11-29 at 06:33 +0200, Peter Eisentraut wrote: > > > I'm not trying to inherit a relation, I'm trying to base a table on > > > it. 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. But the gripe here is the suggestion that the relation > > > would have been inherited, which would actually be achieved using > > > INHERITS. > > > > Interesting. I agree that there's no obvious reason why that > > shouldn't be allowed to work. Could be useful with views, too. > > I recently came across a situation where LIKE with a composite type > might have been useful. > This was the last piece of the puzzle that was missing in this area, for which I have now developed a fix. The problem was that parserOpenTable() rejected composite types. But the only thing that was really adding over using relation_open() directly was nicer error pointers. So I removed a few levels of indirection there, and integrated the error pointer support directly into transformTableLikeClause(). This also has the advantage that the "... is not a table, view, or ..." message now has error pointer support.