From: | Darren Duncan <darren(at)darrenduncan(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: What happened to the is_<type> family of functions proposal? |
Date: | 2010-09-25 03:51:40 |
Message-ID: | 4C9D71CC.1060900@darrenduncan.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
For example, one could say "is_type( <value>, <type-name> )" or it could be
spelled "isa()" or if you wanted to be more ambitious it could be an infix op,
like "<value> isa <type-name>" to test when a value is of a type already.
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.
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.
-- Darren Duncan
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2010-09-25 06:48:34 | Re: BUG #5661: The character encoding in logfile is confusing. |
Previous Message | Craig Ringer | 2010-09-25 03:33:03 | Re: BUG #5661: The character encoding in logfile is confusing. |