Craig James wrote:
Kevin Grittner wrote:
Which leaves the issue open -- a flexible way to flag the *reason* (or
*reasons*) for the absence of a value could be a nice enhancement, if
someone could invent a good implementation. Of course, one could
always add a column to indicate the reason for a
Kevin Grittner wrote:
Which leaves the issue open -- a flexible way to flag the *reason* (or
*reasons*) for the absence of a value could be a nice enhancement, if
someone could invent a good implementation. Of course, one could
always add a column to indicate the reason for a NULL; and perhaps
t
Guy Rouillier wrote:
> Kevin Grittner wrote:
>> A failing of the SQL standard is that it uses the same mark (NULL)
>> to show the absence of a value because it is unknown as for the
>> case where it is known that no value exists (not applicable). Codd
>> argued for a distinction there, but it
Kevin Grittner wrote:
Grzegorz Jaœkiewicz wrote:
A failing of the SQL standard is that it uses the same mark (NULL) to
show the absence of a value because it is unknown as for the case
where it is known that no value exists (not applicable). Codd argued
for a distinction there, but it hasn't
Grzegorz Jaœkiewicz wrote:
> Guy Rouillier wrote:
>> Grzegorz Jaœkiewicz wrote:
>>> using nulls as default 'idunno' - is a bad practice
>> I don't understand this point of view. The concept of null was
>> introduced into the SQL vernacular by Codd and Date expressly to
>> represent unknown val
On Mon, Oct 5, 2009 at 8:35 PM, Guy Rouillier wrote:
> Grzegorz Jaśkiewicz wrote:
>
>>
>> well, as a rule of thumb - unless you can't think of a default value of
>> column - don't use nulls. So using nulls as default 'idunno' - is a bad
>> practice, but everybody's opinion on that differ.
>>
>
> I
Grzegorz Jaśkiewicz wrote:
well, as a rule of thumb - unless you can't think of a default value of
column - don't use nulls. So using nulls as default 'idunno' - is a bad
practice, but everybody's opinion on that differ.
I don't understand this point of view. The concept of null was
introd
Matthew Wakeling writes:
> Yes, that does work, but only because id is NOT NULL. I thought Postgres
> 8.4 had had a load of these join types unified to make it less important
> how the query is written?
NOT IN is not easily optimizable because of its odd behavior in the
presence of nulls. Use
2009/10/5 Matthew Wakeling
>
> Yes, that does work, but only because id is NOT NULL. I thought Postgres
> 8.4 had had a load of these join types unified to make it less important how
> the query is written?
>
well, as a rule of thumb - unless you can't think of a default value of
column - don't
On Mon, 5 Oct 2009, Grzegorz Jaśkiewicz wrote:
On Mon, Oct 5, 2009 at 2:52 PM, Matthew Wakeling wrote:
Table "public.intermineobject"
Column | Type | Modifiers
+-+---
object | text |
id | integer | not null
class | text
On Mon, Oct 5, 2009 at 2:52 PM, Matthew Wakeling wrote:
>
> mnw21-modmine-r13features-copy=# select count(*) from project;
> count
> ---
>10
> (1 row)
>
> mnw21-modmine-r13features-copy=# select count(*) from intermineobject;
> count
> --
> 26344616
> (1 row)
>
> mnw21-modmine-r
mnw21-modmine-r13features-copy=# select count(*) from project;
count
---
10
(1 row)
mnw21-modmine-r13features-copy=# select count(*) from intermineobject;
count
--
26344616
(1 row)
mnw21-modmine-r13features-copy=# \d intermineobject;
Table "public.intermineobject"
Column |
12 matches
Mail list logo
