Marc,
> >This would work, but it would be *much* slower than a UNION query. "Not
> >In" queries are perhaps the slowest you can run; see the earlier thread
> >"Query Problem" for a discussion. UNION queries are, in fact, very fast
> >... just awkward to code and manipulate.
>
> Why should this
Marc, Tom,
> Good point. Frankly, if you have a relevant large population of data
> (>10,000 rows) to test, I'd love to see comparative execution tests
> between the two query structures.
>
> Fortunately, this will all soon become moot; Tom says that outer joins
> have been stable in the 7.1 bu
"pgsql-sql" <[EMAIL PROTECTED]> writes:
> Exported 1131 large objects.
> NOTICE: LockReleaseAll: xid loop detected, giving up
Pre-7.0 LockReleaseAll() contained an entirely arbitrary assumption
that it should never encounter a situation where there were more than
1000 locks held by one transacti
hello,
i am a beginner at SQL and PL/pgsql and thus have some surely
already known problems...
i have set up some tables, and wanted to play around with inbuild
functions, and set up the following function:
CREATE FUNCTION balance (int4) RETURNS int4 AS '
DECLARE
compte ALIAS FOR
> i am a beginner at SQL and PL/pgsql and thus have some surely
> already known problems...
>
> i have set up some tables, and wanted to play around with inbuild
> functions, and set up the following function:
>
> CREATE FUNCTION balance (int4) RETURNS int4 AS '
> DECLARE
>compt
Hi!
I just subscribed myself to this list and sent a message but I am not sure
that
it reached the list. So, I am asking one more time. :-)
Is there any way to implement a query in Postgres that would be in some way
analogues to Oracle's START WITH/CONNECT BY structure?
I'd very much appreciate
Stephan Szabo <[EMAIL PROTECTED]> writes:
> There are still some contexts in which subqueries in expressions are
> wierd. The example below appears to work in current sources however.
>> SELECT COALESCE ((SELECT CURVALUE FROM TABLEKEYS WHERE TABLENAME = 'BUYER'),1)
>> returns a "UNKNOWN expressio
