Re: UNION and rows improperly unified: query optimization question

From: "Marshall Spight" <marshall(at)meetstheeye(dot)com>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: UNION and rows improperly unified: query optimization question
Date: 2002-02-16 07:25:24
Message-ID: a4l1h4$vkr$1@jupiter.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

"Henry House" <hajhouse(at)houseag(dot)com> wrote in message news:20020211200524(dot)GA17170(at)wotan(dot)(dot)(dot)
> Greetings. I have an accounting system in Postgres which has tables
> 'transact' and 'gl_entry'. Each check, deposit, etc has one entry in
> transact, but there may be multiple entries in gl_entry if one check was for
> multiple expenses that are tracked separately (for example, one check to AT=
> &T
> might cover both telephone and Internet service, which are two different
> costing categories). Also, debit and credit are supposed to appear in
> seperate columns, even though they are one number with either positive or
> negative sign in the table. So I run two select and combine them
> using a union statement, but this improperly combines two gl_entry lines th=
> at
> do not differ in amount or transaction ID. My solution is to select also the
> unique ide number from gl_entry and remove it by wrapping the
> SELECT...UNION...SELECT in another SELECT. This seems awfully ugly. Is there
> a better way?

The result of a SELECT statement is a set of values, in the mathematical sense of
the word "set". Sets do not have duplicate values, so here the database is behaving
correctly. That is what UNION means, in SQL, and in any math textbook.

What's wrong with just the inner select? Why do you have to get rid of the
unique id? It's not hurting anything; it's helping in fact.

Marshall

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Josh Berkus 2002-02-16 16:38:05 Psql & Readline
Previous Message Christopher Kings-Lynne 2002-02-16 04:36:30 Re: