At 11:47 27/07/01 +1000, Philip Warner wrote:
>
>...the FROM statement would be a lot nicer if your had a table of SIDs, or
>at least had a good way of generating the list of SIDs.
>
A final (& possibly best) option, is:
Select
MDT.GETFILE,
[anything else from 'best' rec
I try
> select nullif(NULL,5)
++
| case |
++
| |
++
--
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Guard,
> > select nullif(NULL,5)
>
> ++
> | case |
> ++
> | |
> ++
>
Er... what were you expecting, exactly?
Except for IS NULL (and COALESCE, which uses IS NULL) any operation
involving a NULL is also NULL.
-Josh
__AGLIO DATABASE SOLUTIONS__
A Question for those of you who consider yourself crack Database Designers.
I am currently moving a large database(100+Tables) into pgSQL... with the intention of
deploying against 'any' SQL database in the future. The development side will be
rigorously using Standard SQL constructs with no un
A Question for those of you who consider yourself crack Database Designers.
I am currently moving a large database(100+Tables) into pgSQL... with the intention of
deploying against 'any' SQL database in the future. The development side will be
rigorously using Standard SQL constructs with no un
I'm by no means a crack database designer, but I do have my ideas on this
subject. I prefer that every table has a unique integer (auto-incrementing)
primary key. Why? Consistency. With the alternative, some tables may not
have a clear-cut candidate for a unique id. In your example, you had
"
You would not necessarily want clients searching by the integer-based key.
That is used internally by the database or application. Clients wouldn't
know what the keys are anyway because they are not used for anything except
referential integrity/relation of data. You would have Part_ID, and
Part
Phillip,
> What it effectively does is executes the second SELECT for each row
> of the
> first select, a bit like a column-select expression, but it allows
> access
> to all rows.
Ah! I knew that there had to be a simple way to do what you want to do
in PGSQL:
SELECT MIN(getfile) as bestfile
At 17:19 27/07/01 -0700, Josh Berkus wrote:
>Phillip,
>
>> What it effectively does is executes the second SELECT for each row
>> of the
>> first select, a bit like a column-select expression, but it allows
>> access
>> to all rows.
>
>Ah! I knew that there had to be a simple way to do what you w
Can anyone tell me why this always return 1? Thanks!
CREATE FUNCTION passrate(date, date, text) RETURNS float AS '
DECLARE
begindate ALIAS FOR $1;
enddate ALIAS FOR $2;
passfail ALIAS FOR $3;
ret float;
countp float;
counttotal float;
BEGIN
SELECT INTO countp COUNT(*)
FROM benchmar
On Fri, 27 Jul 2001, Jimmie Fulton wrote:
> I'm by no means a crack database designer, but I do have my ideas on this
> subject. I prefer that every table has a unique integer (auto-incrementing)
> primary key. Why? Consistency. With the alternative, some tables may not
> have a clear-cut can
On Fri, 27 Jul 2001, John Oakes wrote:
> Can anyone tell me why this always return 1? Thanks!
>
> CREATE FUNCTION passrate(date, date, text) RETURNS float AS '
>
> DECLARE
> begindate ALIAS FOR $1;
> enddate ALIAS FOR $2;
> passfail ALIAS FOR $3;
> ret float;
> countp float;
> counttota
12 matches
Mail list logo
