Re: What happened to the is_ family of functions proposal?

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/