Re: Types pollution with iso-8859-1 oids and server-side parameters binding

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

> Extrapolating this particular suggested change from one example seems dangerous.  Particularly since much of this is
limitedto the case of treating a timestamp as both a timestamp and date at the same time.  Making any change from what
isseemingly 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
surethere are other concerns given the layer of indirection, but a general rule to "always cast your parameters" goes a
longway 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