| From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | "Greg Stark" <stark(at)enterprisedb(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Dave Page" <dpage(at)pgadmin(dot)org>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New to_timestamp implementation is pretty strict |
| Date: | 2008-12-01 19:00:50 |
| Message-ID: | 603c8f070812011100j4d6b990ftd98fbd531f635123@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> For better or worse, we also allow these more questionable inputs:
Wow. Those are all pretty atrocious.
Even so, it's not clear to me that there's a lot of merit to changing
the behavior. If to_timestamp() isn't rigorous enough, you can always
stick some additional error checking in front of it; it's easy to
write a regular expression that will only match EXACTLY YYYY-MM-DD if
that's what you want to do. If to_timestamp() is excessively
pedantic, it forces you into rewriting to_timestamp(), which is a lot
more work. I probably still wouldn't make it accept anything quite
as... creative... as these examples if starting over, but now that the
existing version is out there, I think breaking backward compatibility
isn't warranted.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Sabino Mullane | 2008-12-01 19:31:49 | Re: Statement-level triggers and inheritance |
| Previous Message | Heikki Linnakangas | 2008-12-01 18:46:41 | Re: New to_timestamp implementation is pretty strict |