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

Поиск
Список
Период
Сортировка
От Darren Duncan
Тема Re: What happened to the is_ family of functions proposal?
Дата
Msg-id 4C9D71CC.1060900@darrenduncan.net
обсуждение исходный текст
Ответ на What happened to the is_ family of functions proposal?  ("Colin 't Hart" <colinthart@gmail.com>)
Ответы Re: What happened to the is_ family of functions proposal?  (Craig Ringer <craig@postnewspapers.com.au>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: BUG #5661: The character encoding in logfile is confusing.
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: BUG #5661: The character encoding in logfile is confusing.