Re: Do we want a hashset type?

On 6/19/23 13:50, Andrew Dunstan wrote:
> 
> On 2023-06-19 Mo 05:21, Tomas Vondra wrote:
>> On 6/18/23 18:45, Andrew Dunstan wrote:
>>> On 2023-06-16 Fr 20:38, Joel Jacobson wrote:
>>>> New patch is attached, which will henceforth always be a complete patch,
>>>> to avoid the hassle of having to assemble incremental patches.
>>> Cool, thanks.
>>>
>> It might still be convenient to keep it split into smaller, easier to
>> review, parts. A patch that introduces basic functionality and then
>> patches adding various "advanced" features.
>>
>>> A couple of random thoughts:
>>>
>>>
>>> . It might be worth sending a version number with the send function
>>> (c.f. jsonb_send / jsonb_recv). That way would would not be tied forever
>>> to some wire representation.
>>>
>>> . I think there are some important set operations missing: most notably
>>> intersection, slightly less importantly asymmetric and symmetric
>>> difference. I have no idea how easy these would be to add, but even for
>>> your stated use I should have thought set intersection would be useful
>>> ("Who is a member of both this set of friends and that set of friends?").
>>>
>>> . While supporting int4 only is OK for now, I think we would at least
>>> want to support int8, and probably UUID since a number of systems I know
>>> of use that as an object identifier.
>>>
>> I agree we should aim to support a wider range of data types. Could we
>> have a polymorphic type, similar to what we do for arrays and ranges? In
>> fact, CREATE TYPE allows specifying ELEMENT, so wouldn't it be possible
>> to implement this as a special variant of an array? Would be better than
>> having a set of functions for every supported data type.
>>
>> (Note: It might still be possible to have a special implementation for
>> selected fixed-length data types, as it allows optimization at compile
>> time. But that could be done later.)
> 
> 
> Interesting idea. There's also the keyword SETOF that we could possibly
> make use of.
> 
> 
>> The other thing I've been thinking about is the SQL syntax and what does
>> the SQL standard says about this.
>>
>> AFAICS the standard only defines arrays and multisets. Arrays are pretty
>> much the thing we have, including the ARRAY[] constructor etc. Multisets
>> are similar to hashset discussed here, except that it tracks the number
>> of elements for each value (which would be trivial in hashset).
>>
>> So if we want to make this a built-in feature, maybe we should aim to do
>> the multiset thing, with the standard SQL syntax? Extending the grammar
>> should not be hard, I think. I'm not sure of the underlying code
>> (ArrayType, ARRAY_SUBLINK stuff, etc.) we could reuse or if we'd need a
>> lot of separate code doing that.
>>
>>
> 
> Yes, Multisets (a.k.a. bags and a large number of other names) would be
> interesting. But I wouldn't like to abandon pure sets either. Maybe a
> typmod indicating the allowed multiplicity of the type?
> 

Maybe, although I'm not sure if that can be specified with a multiset
constructor, i.e. when using MULTISET[...] in places where we now use
ARRAY[...] to specify arrays.

I was thinking more about having one set of operators, one considering
the duplicity (and thus doing what SQL standard says) and one ignoring
it (thus treating MULTISETS as plain sets).

Anyway, I'm just thinking aloud. I'm not sure if this is the way to do,
but it'd be silly to end up implementing stuff unnecessarily and/or
inventing something that contradicts the SQL standard (or is somehow
inconsistent with similar stuff).


regard

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company