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

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

In response to

Responses

Browse pgsql-hackers by date

  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.