On 10/16/2013 08:18 AM, Stephen Frost wrote:
> As it relates to this specific patch for this CF, I'd go with 'Returned
> with Feedback' and encourage you to consider the arguments for and
> against, and perhaps try to find existing usage which would break due to
> this change and consider the impact of changing it. For example, what
> do the various languages and DB abstraction layers do today? Would
> users of Hibernate likely be impacted or no? What about PDO?
> Personally, I'm still on-board with the change in general, but it'd
> really help to know that normal/obvious usage through various languages
> won't be busted by the change.
I'm fairly sure that the only language likely to be impacted chronically
is PHP. Java, Ruby and Python, as a rule, properly data-type their
parameters; PHP is the only language I know of where developers *and
frameworks* chronically pass everything as a string. IIRC, the primary
complainers when we removed a bunch of implicit casts in 8.3 were PHP devs.
One thing to keep in mind, though, is that few developers actually use
pg_sleep(), and I'd be surprised to find in in any canned web framework.Generally, if a web developer is going to
sleep,they do it in the
application. So we're really only talking about stored procedure
writers here. And, as a rule, we can expect stored procedure writers to
not gratuitously use strings in place of integers.
We generally don't bounce PLpgSQL features which break unsupported
syntax in PLpgSQL, since we expect people who write functions to have a
better knowledge of SQL syntax than people who don't. I think
pg_sleep(interval) falls under the same test. So I'd vote to accept it.
Also, as Tom pointed out, at some point we have to either say we really
support overloading or we don't.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com