Thanks for those two maximally terse examples, Christophe. They illustrate the same point that my larger examples aimed at. (Forgive me for not working more to distill mine down to what you showed.) Unquestionably, this is surprising! Well, surprise is in the eye of the beholder. I was surprised at first because I hadn't joined the dots from:
to
But now I've changed the way that I see this—thanks to your replies and to Tom's. See my reply to Tom here: I'll now adopt a very simple model for when "identifier could not be resolved" errors surface:
This is what matters: — The fact that the semantics of (embedded) SQL and _expression_ evaluation are down to a single implementation, and are therefore identical in both top-level SQL and in PL/pgSQL, are enormous. (This stands in stark contrast to Oracle's PL/SQL where there are two implementations that bring inevitable divergences in semantics are limitations.) — Self-evidently, runtime testing is all that ultimately matters. The more of this I do, and the sooner I do it, the better will be my outcomes. — The practical advantages of later semantic checking that you've both pointed out are huge. For example, create a temporary table and use it *in the same block statement*. And now (for the second time) "case closed". |
