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  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Christoph Berg
Дата:
Сообщение: Re: Runtime SHAREDIR for testing CREATE EXTENSION
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Runtime SHAREDIR for testing CREATE EXTENSION