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

On Wed, 4 May 2022 at 01:06, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> Extrapolating this particular suggested change from one example seems dangerous. Particularly since much of this is limited to the case of treating a timestamp as both a timestamp and date at the same time. Making any change from what is seemingly a rare corner-case doesn't seem to provide a sufficient benefit/cost ratio.
>
> I have to put this into the "unfortunate foot-gun" category at this point. Users should be testing their code. I'm sure there are other concerns given the layer of indirection, but a general rule to "always cast your parameters" goes a long way if one chooses to avoid the API where explicit parameter types can be supplied. Or at least "cast once, cast always" for any given parameter.

Yes, this was admittedly a contrived case, not only for the use of ts,
but also because ts was passed as a string rather than a Python
datetime, which would have resulted in the parameter oid specified.
So, many layers of good practices weren't followed in the first
place... making me think that specifying such a corner case in the
documentation would have limited utility (a rare occurrence mostly
encountered if someone doesn't read the docs).

-- Daniele