Re: 8.1.3, libpq, PQprepare, plpgsql function, and partitioned tables

Поиск
Список
Период
Сортировка
От shakahshakah@gmail.com
Тема Re: 8.1.3, libpq, PQprepare, plpgsql function, and partitioned tables
Дата
Msg-id 1144069915.081245.11910@u72g2000cwu.googlegroups.com
обсуждение исходный текст
Ответ на 8.1.3, libpq, PQprepare, plpgsql function, and partitioned tables  ("shakahshakah@gmail.com" <shakahshakah@gmail.com>)
Список pgsql-general
Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > "shakahshakah@gmail.com" <shakahshakah@gmail.com> writes:
> > > Am I correct in assuming that when Postgres prepared the SQL to execute
> > > the "insert function" that the existing rules on the base table were
> > > also resolved at that time?  If so, is there any way to avoid that
> > > behavior?
> >
> > Yes; no.  We are working on infrastructure to automatically redo
> > prepared plans when relevant catalog entries change, but it's not there
> > today :-(
>
> Wouldn't it be possible to use 'execute' instead and have the plan
> re-generated each time that way?  It'd be less efficient but I think
> it'd work as a work-around...

Thank you both for the responses. Though I haven't tried it yet I
suspect that using 'execute' would work in my case.

However, my initial expectation was that preparing the stored procedure
call would be limited to consulting the catalog for the stored
procedure name, the args, the arg types, etc. Would the behavior be
different if the stored procedure were more complicated (rather than
the current thin shell around a single INSERT stmt)?


В списке pgsql-general по дате отправления:

Предыдущее
От: sconeek@gmail.com
Дата:
Сообщение: Re: Cant find temp tables
Следующее
От: ptjm@interlog.com (Patrick TJ McPhee)
Дата:
Сообщение: Re: PSQL Data Type: text vs. varchar(n)