From: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MySQL search query is not executing in Postgres DB |
Date: | 2012-02-18 16:51:22 |
Message-ID: | 8fa4bac539df891a13b01f98806190d7@biglumber.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> The time I got bitten by this was actually with LPAD(), rather than LIKE.
+1. This is one of the functions that gave some of our clients
real trouble when 8.3 came out.
> If we really believed that implicit casts any form were evil, we
> would have removed them entirely instead of trimming them back.
> I don't see why it's heretical to suggest that the 8.3 casting
> changes brought us to exactly that point in the universe where
> everything is perfect and nothing can be further improved; does
> anyone seriously believe that?
Agreed (although the last bit is a bit of a straw man). The idea
in this thread of putting some implicit casts into an extension
or other external package is not a very good one, either. Let's
apply some common sense instead, and stick to our guns on the ones
where we feel there could honestly be serious app consequences and
thus we encourage^H^Hforce people to change their code (or write all
sorts of custom casts and functions). I think the actual number of
such app circumstances is rather small, but my clients are not your*
clients, so who knows? In other words, I'll concede int==text, but
really need a strong argument for conceding things like LPAD.
* Your = everyone else, not just M. Haas.
- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201202181145
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAk8/1usACgkQvJuQZxSWSsjE6ACdHy31jpHUsXo5juvXcCkzKpGH
RQAAoM/uTbM/JBkDiDjrsI1Blyg3DsWf
=7CA4
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Rijkers | 2012-02-18 16:58:19 | pg_restore ignores PGDATABASE |
Previous Message | Tom Lane | 2012-02-18 16:41:53 | mul_size() overflow check broken in win64 builds? |