From: | "Richard Ellerbrock" <richarde(at)eskom(dot)co(dot)za> |
---|---|
To: | <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: REPOST: Trouble with SQL conversion |
Date: | 2002-04-11 15:48:02 |
Message-ID: | scb5cc57.078@eskom.co.za |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Ok, now the academic part - why do you have to "GROUP BY" all columns
selected? Would one not suffice and have the optimizer figure out the
rest? I am no standards guru and have not studied SQL92 or SQL99 so
would just like to know.
Another inconsistency that I have picked up is with transactions. If I
insert a record and violate a primary key (in a transaction block, on
both databases) I get an error to the fact - correct. After the error, I
am not allowed to do anything, even a select. I am trying to simulate a
replace into the database, but using an insert, if failure update does
not work. I have worked around this by first trying an update, check the
number of affected rows, if zero then insert. This works.
So my question: If an insert fails in a transaction is all access dead
forever, even selects till the transaction is rolled back or committed?
Once again what does the standard say.
>>> Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> 2002/04/11
05:36:12 >>>
> I am an idiot! Actually your suggestion does work - it would help to
do
> it against a customer that actually has records!
Phew! Lucky that "other" database didn't have one over us, huh? ;)
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Gordon Clarke | 2002-04-11 20:59:53 | Re: Functions in Postgres |
Previous Message | Christopher Kings-Lynne | 2002-04-11 15:36:12 | Re: REPOST: Trouble with SQL conversion |