Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »

Поиск
Список
Период
Сортировка
От Bryn Llewellyn
Тема Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »
Дата
Msg-id C4FB1CF4-AF47-4443-B7D2-94CB817D4666@yugabyte.com
обсуждение исходный текст
Ответ на Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »  (Christophe Pettus <xof@thebuild.com>)
Ответы Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »  (Christophe Pettus <xof@thebuild.com>)
Список pgsql-general
xof@thebuild.com wrote:

bryn@yugabyte.com wrote:

Is this expected?

Yes.  This isn't a bug… Database objects (such as tables and columns) are left as identifiers until they are executed, because that is the point at which a plan for those statements is created.  The other components of PL/pgSQL are translated to internal form (and thus checked for existence) at compile time.

My example was carefully contrived to test what you said—which is what I had earlier understood. My deliberate typo thus:

change "v_message" in "z := v_message;  return next;" to "q_message"

(surely) has nothing to do with possible database objects. The context is a straight PL/pgSQL assignment statement (with no scalar subquery in sight).

It's this that surprises me. And it's this, and only this, that I'm asking about: might _just_ this be a fixable bug?

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

Предыдущее
От: Christophe Pettus
Дата:
Сообщение: Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »