Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: krisDate: 2009-06-13 16:13:47
Subject: Re: PostgreSQL Developer meeting minutes up
Previous:From: Tom LaneDate: 2009-06-13 13:57:59
Subject: Re: pgindent run coming

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group