po 20. 1. 2020 v 1:38 odesÃlatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Paul A Jungwirth <p...@illuminatedcomputing.com> writes: > > On Sun, Jan 19, 2020 at 12:10 AM Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >> Now, I think so name "anymultirange" is not good. Maybe better name is > just "multirange" > > > Are you sure? This function exists to be a cast to an anymultirange, > > and I thought the convention was to name cast functions after their > > destination type. > > True for casts involving concrete types, mainly because we'd like > the identity "value::typename == typename(value)" to hold without > too much worry about whether the latter is a plain function call > or a special case. Not sure whether it makes as much sense for > polymorphics, since casting to a polymorphic type is pretty silly: > we do seem to allow you to do that, but it's a no-op. > > I'm a little troubled by the notion that what you're talking about > here is not a no-op (if it were, you wouldn't need a function). > That seems like there's something fundamentally not quite right > either with the design or with how you're thinking about it. > I thinking about completeness of operations I can to write CREATE OR REPLACE FUNCTION fx(anyarray, anyelement) RETURNS anyarray AS $$ SELECT $1 || ARRAY[$2] $$ LANGUAGE sql; I need to some functionality for moving a value to different category (it is more generic than casting to specific type (that can hold category) CREATE OR REPLACE FUNCTION fx(anymultirange, anyrange) RETURNS anyrage AS $$ SELECT $1 + multirange($1) $$ LANGUAGE sql; is just a analogy. Regards Pavel > As a comparison point, we sometimes describe subscripting as > being a polymorphic operation like > > subscript(anyarray, integer) returns anyelement > > It would be completely unhelpful to call that anyelement(). > I feel like you might be making a similar mistake here. > > Alternatively, consider this: a cast from some concrete multirange type > to anymultirange is a no-op, while any other sort of cast probably ought > to be casting to some particular concrete multirange type. That would > line up with the existing operations for plain ranges. > > regards, tom lane >
