Re: What happened to the is_ family of functions
proposal?
От | Darren Duncan |
---|---|
Тема | Re: What happened to the is_ |
Дата | |
Msg-id | 4C9D71CC.1060900@darrenduncan.net обсуждение исходный текст |
Ответ на |
What happened to the is_ |
Ответы |
Re: What happened to the is_ |
Список | 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 по дате отправления: