On 25/09/2010 11:51 AM, Darren Duncan wrote:
Colin 't Hart wrote:
The fact that this wraps would seem to me to make the implementation
of is_date() difficult.
Having separate is_foo() syntax per type is a bad design idea, same as
having a different equality test like eq_int() or assignment syntax like
assign_str() per type.
There should just be a single syntax that works for all types, in the
general case, for testing whether a value is a member of that type, or
alternately whether a value can be cast to a particular type.
Good point. That also permits a general-case implementation that catches
any exceptions thrown, with optimized exception-free cases for
int/date/string etc behind the scenes.
That'd do a good job of protecting the SQL programmer from having to
deal with which types had tests and which they had to use exception
handling for. It'd have to be documented due to the performance
differences, but it'd be great to be able to do this in a general
purpose way at the SQL level.
Pg already gets it right in this regard by having a single general
syntax for type casting, the "<value>::<type-name>" and value membership
of a type should be likewise.
or the standard:
CAST(value AS typename)
Maybe to test if a value can be cast as a type, you can continue the ::
mnemonic, say adding a "?" for yes and a "!" for no.
For example, "<value>?::<type-name>" tests if the value can be cast as
the type and "<value>!::<type-name>" or "not <value>?::<type-name>"
tests the opposite. An expression like this results in a boolean.
Personal opinion here: Blech, if I wanted to use Perl6 I'd do so ;-)
Good shorthand, I guess, but a CAST syntax extension or alternate CAST
version would be a bonus for readability.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
