Got it. Thanks!
Scott
On Mar 1, 2005, at 10:52 PM, Ragnar Hafstað wrote:
On Tue, 2005-03-01 at 16:51 -0800, Scott Frankel wrote:
Sweet! And not so sweet.
The natural join worked beautifully with my test schema; but it failed
to yield any rows with my real-world schema. I think I've tracked
down
On Tue, 2005-03-01 at 16:51 -0800, Scott Frankel wrote:
> Sweet! And not so sweet.
>
> The natural join worked beautifully with my test schema; but it failed
> to yield any rows with my real-world schema. I think I've tracked down
> why: duplicate column names. i.e.:
> ...
> CREATE TABLE
Sweet! And not so sweet.
The natural join worked beautifully with my test schema; but it failed
to yield any rows with my real-world schema. I think I've tracked down
why: duplicate column names. i.e.:
-1- these tables yield rows from a NATURAL JOIN query
CREATE TABLE palettes (palette_
On Tue, 2005-03-01 at 13:42 -0800, Scott Frankel wrote:
> [snip problem]
> Task: find all color names in each of palette1's tones.
>
> Can this be done in a single SQL statement?
> [snip table examples]
looks like a job for NATURAL JOIN
test=# select color_name
from palettes
I want to return all records that match criteria across three separate
tables
and , in spite of reading up on joins, have so far been unable to
design a
solution that doesn't require caching a hash table of intermediate
results.
Here's the situation:
Let's say color names belong to a set of ton
