On Thu, Jun 23, 2016 at 12:37 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote
> To be honest I don't see how this is relevant to quoted content. And you've
> already made this point quite clearly - repeating it isn't constructive.
> This behavior has existed for a long time and I don't see that changing it
> is a worthwhile endeavor. I believe a new function is required that has
> saner behavior. Otherwise given good input and a well-formed parse string
> the function does exactly what it is designed to do. Avoid giving it
> garbage and you will be fine. Maybe wrap the call to the in a function that
> also checks for the expected layout and RAISE EXCEPTION if it doesn't match.
Well, I think other people are allowed to disagree about whether
changing it is a worthwhile endeavor. I think there's an excellent
argument that the current behavior is stupid and broken and probably
nobody is intentionally relying on it.
Obviously, if somebody is relying on the existing behavior and we
change it and it breaks things, then that's bad, and a good argument
for worrying about backward-compatibility - e.g. by adding a new
function. But who would actually like the behavior that an extra
space in the format string causes non-whitespace characters to get
skipped? Next you'll be arguing that we can't fix a server crash
that's triggered by a certain query because somebody might be relying
on that query to restart the server...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
