Re: range_agg
От | Paul A Jungwirth |
---|---|
Тема | Re: range_agg |
Дата | |
Msg-id | CA+renyXBRAq0HH=xS3MSiLb5AhXbddg=BGCjjs0JaHmNqPXRjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: range_agg (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: range_agg
|
Список | pgsql-hackers |
On Sun, Jan 19, 2020 at 4:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. > > ... > > 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. I agree you wouldn't actually cast by saying x::anymultirange, and the casts we define are already concrete, so instead you'd say x::int4multirange. But I think having a polymorphic function to convert from an anyrange to an anymultirange is useful so you can write generic functions. I can see how calling it "anymultirange" may be preferring the implementor perspective over the user perspective though, and how simply "multirange" would be more empathetic. I don't mind taking that approach. Yours, Paul
В списке pgsql-hackers по дате отправления: