> On 08 Dec 2015, at 07:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> Trying to decide which characters are legitimate noise and which
> aren't seems like a tarbaby best not to get stuck to :-(
I'd like to argue that if you need PostgreSQL-native time from a string, and=
want more control and verification, that's probably something that's best l=
eft to the application anyway.
I fail to see how PostgreSQL can reasonably be made to be "perfect" for all p=
ossible cases of dirty input being casted to interval.
The application is in a much better position to deal with this, presumably k=
nowing more about the input, and being a cleaner place to put any parsing an=
d handling.=20
=46rom there, it can be passed to PostgreSQL either as a native interval obj=
ect, or a cleaned up string.=20
In other words, I agree about not changing the behavior.=20
That said, I do wonder if it could be worthwhile to consider having an optio=
n to trigger a notice or error upon dirty bytes getting skipped, as a way of=
declaring "all input should be clean (now), please accept nothing less". Th=
e again, that certainly falls outside the scope of -bugs@.=20
Terje=
