On July 8, 2015 at 1:36:49 PM, Tom Lane (t...@sss.pgh.pa.us) wrote:
Paul Ramsey writes:
>> UNION will preferentially glom onto the btree equality operator, if memory
>> serves. If that isn't also the hash equality operator, things won't work
>> pleasantly.
> So… what does that mean for typ
Paul Ramsey writes:
>> UNION will preferentially glom onto the btree equality operator, if memory
>> serves. If that isn't also the hash equality operator, things won't work
>> pleasantly.
> So⦠what does that mean for types that have both btree and hash equality
> operators? Donât all
> It still says I lack the secret sauce...
> ERROR: could not implement recursive UNION
> DETAIL: All column datatypes must be hashable.
UNION will preferentially glom onto the btree equality operator, if memory
serves. If that isn't also the hash equality operator, things won't work
p
Paul Ramsey writes:
> On Fri, Apr 25, 2014 at 4:54 PM, Peter Geoghegan wrote:
>> On Fri, Apr 25, 2014 at 4:47 PM, Paul Ramsey
>> wrote:
>>> Is it possible to make custom types hashable? There's no hook in the
>>> CREATE TYPE call for a hash function, but can one be hooked up
>>> somewhere else?
On Fri, Apr 25, 2014 at 4:54 PM, Peter Geoghegan wrote:
> On Fri, Apr 25, 2014 at 4:47 PM, Paul Ramsey
> wrote:
>> Is it possible to make custom types hashable? There's no hook in the
>> CREATE TYPE call for a hash function, but can one be hooked up
>> somewhere else? In an operator?
>
> See 35.
Greg Stark writes:
> On Sat, Apr 26, 2014 at 6:39 PM, Atri Sharma wrote:
>> Without sorting, isnt the scope of a recursive UNION with custom datatypes
>> pretty restrictive?
> All the default data types are hashable. It's not hard to add a hash
> operator class. In a clean slate design it would
On Sat, Apr 26, 2014 at 6:39 PM, Atri Sharma wrote:
> Without sorting, isnt the scope of a recursive UNION with custom datatypes
> pretty restrictive?
All the default data types are hashable. It's not hard to add a hash
operator class. In a clean slate design it would probably have been
simpler t
The plain UNION code supports either sorting or hashing, but
> we've not gotten around to supporting a sort-based approach
> to recursive UNION. I'm not convinced that it's worth doing ...
>
> regards, tom lane
>
>
>
Without sorting, isnt the scope of a recursive UNION with
David Fetter writes:
> On Fri, Apr 25, 2014 at 04:47:49PM -0700, Paul Ramsey wrote:
>> ERROR: could not implement recursive UNION
>> DETAIL: All column datatypes must be hashable.
> This leads to an interesting question, which is why does our
> implementation require this. I'm guessing it's a
On Fri, Apr 25, 2014 at 04:47:49PM -0700, Paul Ramsey wrote:
> When trying to write a recursive CTE using the PostGIS geometry type,
> I was told this:
>
> ERROR: could not implement recursive UNION
> DETAIL: All column datatypes must be hashable.
This leads to an interesting question, which is
On Fri, Apr 25, 2014 at 4:47 PM, Paul Ramsey wrote:
> Is it possible to make custom types hashable? There's no hook in the
> CREATE TYPE call for a hash function, but can one be hooked up
> somewhere else? In an operator?
See 35.14.6., System Dependencies on Operator Classes
--
Peter Geoghegan
When trying to write a recursive CTE using the PostGIS geometry type,
I was told this:
ERROR: could not implement recursive UNION
DETAIL: All column datatypes must be hashable.
Is it possible to make custom types hashable? There's no hook in the
CREATE TYPE call for a hash function, but can one
12 matches
Mail list logo
