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

From: Bryn Llewellyn <bryn(at)yugabyte(dot)com>
To: Christophe Pettus <xof(at)thebuild(dot)com>
Cc: pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »
Date: 2022-07-29 01:49:32
Message-ID: C4FB1CF4-AF47-4443-B7D2-94CB817D4666@yugabyte.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> xof(at)thebuild(dot)com wrote:
>
>> bryn(at)yugabyte(dot)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?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2022-07-29 02:04:02 Re: Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »
Previous Message Christophe Pettus 2022-07-29 01:23:30 Re: « The PL/pgSQL interpreter parses the function's source text and produces an internal binary instruction tree... »