From: | "Jonathan S(dot) Katz" <jonathan(dot)katz(at)excoventures(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: point types in "DISTINCT" queries |
Date: | 2011-06-29 16:24:28 |
Message-ID: | C0AEF0AB-4C42-4410-9F23-8BA0BCB3BC11@excoventures.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Wed, 2011-06-29 at 11:37 -0400, Jonathan S. Katz wrote:
>> Which means it *should* work, but first I would need to clean up the data and find the duplicates. I was hoping this might work:
>>
>> SELECT geocode, count(*)
>> FROM a
>> GROUP BY a.geocode
>> HAVING count(*) > 1;
>
> Maybe you could use a self-join as a workaround for now, just to clean
> up the data?
>
> SELECT geocode, other_columns from a a1, a a2 where a1.other_columns <>
> a2.other_columns and a1.geocode ~= a2.geocode;
That worked perfectly - turned out it was just two rows. And subsequently executing the exclusion constraint on "=~" also worked perfectly as expected.
The larger issue I face with now is slightly out of my control without further hacking. I'm developing an app with Django and I wrote an extension that allows me to use the point type natively in Python. I ran into the original issue while an automatically generated query was executed in the admin section. I know this could be viewed as something pertaining to Django, but the goal I had in mind was making PostgreSQL functionality more accessible in a different software layer.
I will find a workaround for the above, as I am sure I can do some application-level hacking.
Thanks for your help!
Jonathan
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Saito | 2011-06-29 16:38:21 | Re: Windows x64 : How do I get OSSP-UUID.sql contrib for postgresql x64 |
Previous Message | Scott Ribe | 2011-06-29 16:19:05 | Re: Real type with zero |