Re: Misleading CREATE TABLE error
От | Peter Eisentraut |
---|---|
Тема | Re: Misleading CREATE TABLE error |
Дата | |
Msg-id | 1330074192.32452.4.camel@vanquo.pezone.net обсуждение исходный текст |
Ответ на | Re: Misleading CREATE TABLE error (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Misleading CREATE TABLE error
|
Список | pgsql-hackers |
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.
Вложения
В списке pgsql-hackers по дате отправления: