| 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: | Whole Thread | Raw Message | 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. |