Re: Types pollution with unknown oids and server-side parameters binding

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Types pollution with unknown oids and server-side parameters binding
Date: 2022-05-03 22:18:52
Message-ID: 2234572.1651616332@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Tue, May 3, 2022 at 12:55 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> What do you think ought to happen? The same parameter somehow having
>> different types in different places?

> Based upon:
> "When a parameter's data type is not specified or is declared as unknown,
> the type is inferred from the context in which the parameter is first
> referenced (if possible)."

Right ...

> The parameter would seem to be first referenced as a timestamp (at least in
> parsing order).

Actually, if you look at transformUpdateStmt, you'll see the parsing
order is WITH, then FROM, then WHERE, then RETURNING, then the targetlist.
Some of this is constrained by semantics: we have to do WITH first because
it'll define pseudo-tables used in FROM, and we have to do FROM before
we can make sense of the rest. We could possibly do the targetlist
before WHERE, but any assumption that it works left-to-right is just
doomed to failure by the poor consistency of SQL syntax.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Daniele Varrazzo 2022-05-03 22:35:11 Re: Types pollution with unknown oids and server-side parameters binding
Previous Message David G. Johnston 2022-05-03 20:31:08 Re: Types pollution with unknown oids and server-side parameters binding