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
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
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
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
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
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
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
"
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
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__
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])
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
12 matches
Mail list logo
