, and
notify the user once resuilts are available
} else {
run the query and wait for the results in real time.
}
Thanks,
Alan
--
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql
On Saturday 14 January 2006 13:09, A. Kretschmer wrote:
> am 14.01.2006, um 13:02:48 + mailte Alan Chandler folgendes:
> > select name, id, transaction.date as tdate, description, amount
> > from account join transaction on name=dst where name ='Sarah'
> > or
ah | 15 | 0005-06-10 | Petrol Allowance |-40
Sarah | 11 | 2005-06-05 | Sarah Petrol | 27.74
(5 rows)
I can't figure out why the dates are not in order (see transaction 11 is out
of place).
for reference the transaction table has the "date" field of ty
I can't see a
column in this table that could potentially correspond and therefore I could
join to it.
Help
--
Alan Chandler
http://www.chandlerfamily.org.uk
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
sql
> programming style? faster?
Better style, yes. Whitespace would help also.
Faster, maybe. If you use join clauses you will be able to take control
over your query, specifying what gets joined when.
--
Alan Gutierrez - [EMAIL PROTECTED]
http://khtml-win32.sourceforge.n
dards,
so posting using the standard is his way of boosting them.
BEGIN ATOMIC is BEGIN in PG.
I am not sure how to declare a variable in PG in normal SQL. I don't do
it that often, but when I do I do this:
CREATE TEMPORARY TABLE Rightmost_Spread
AS SELECT rightmost_spread
FROM Fram
ql with the -E argument to see
the SQL used to run \dt. Look at man psql for for info for just:
psql -E template1
Alan Gutierrez
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
to debate C++
here! Its just that C++ is what made my knee jerk.
Thanks for showing me the value of operator overloading in PostgreSQL.
Alan
On Tue, 14 Aug 2001, Ross J. Reedstrom wrote:
> On Tue, Aug 14, 2001 at 06:51:33AM +, Alan Gutierrez wrote:
> >
> > Overloading operato
So an attempt to
>
> UPDATE t1 SET id = 2 WHERE id = 1;
>
> is the thing prevented in your above example.
I find it odd that you specify a restiction on one table in the definition of
another table.
Sorry, if this was a double post.
Alan Gutierrez
--
