Re: some of the datatypes only support hashing, while others only support sorting

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: some of the datatypes only support hashing, while others only support sorting
Date: 2009-06-13 15:10:21
Message-ID: 11087.1244905821@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> This errdetail doesn't seem quite right in the following situation:
> rhaas=# select distinct proacl from pg_proc;
> ERROR: could not implement DISTINCT
> DETAIL: Some of the datatypes only support hashing, while others only
> support sorting.

Hmm, interesting case. The reason the planner is assuming that that
must be the failure mode is that the parser is not supposed to let
through a DISTINCT request for a datatype that can't be either sorted
or hashed. proacl is of course of aclitem[], and type aclitem has a
hashable equality operator but no sort operator. Which causes
get_sort_group_operators() to assume that aclitem[] can likewise be
hashed but not sorted. However, there is no hash opclass for anyarray,
so actually it's not hashable either; and the test the planner uses
discovers that.

It seems like we ought to add opclass entries and an anyarray hash
function, but of course it's too late for that for 8.4.

What I'll do for the moment is kluge up get_sort_group_operators()
to reflect the fact that arrays are only sortable and not hashable.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message kris 2009-06-13 16:13:47 Re: PostgreSQL Developer meeting minutes up
Previous Message Tom Lane 2009-06-13 13:57:59 Re: pgindent run coming