(damn gmail, sorry about priv mail earlier)
Stephan Szabo <[EMAIL PROTECTED]>:
I think putting a test in an ON clause associated with the join (using
something like ... left join object_values ov1 ON(ov.obj_id = ov1.obj_id
and ov1.att_id=8) rather than where will consider both as part of the joi
Emils <[EMAIL PROTECTED]> writes:
> The table structure is:
> object_values
> ==
> obj_id
> att_id
> value
> namely, each object can have arbitrary number of attributes each of
> them with a value.
> What I want, is a simple table of objects with some of their specific
> attributes, the
On Fri, 28 Apr 2006, Emils wrote:
> I am trying to do simple self-joins.
>
> The table structure is:
>
> object_values
> ==
> obj_id
> att_id
> value
>
> namely, each object can have arbitrary number of attributes each of
> them with a value.
>
> What I want, is a simple table of objects w
Hello!
I am a longtime postgres user (started around 10 years ago), however,
as for some years I've been using it mostly as administrator.
Now that I have started a project and doing some SQL, I've come up
something I don't believe is right. Maybe I am too rusty on my SQL -
if so, please forgive
Alex Pilosov <[EMAIL PROTECTED]> writes:
> I'm going to CC this to -hackers, maybe someone will shed a light on the
> internals of this.
It's not unintentional. See
http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/explicit-joins.html
regards, tom lane
--
On Mon, 24 Sep 2001, Alex Pilosov wrote:
> On Sun, 23 Sep 2001, Stephan Szabo wrote:
>
> > On Sun, 23 Sep 2001, Alex Pilosov wrote:
> >
> > Postgres treats join syntax as an explicit definition of what order to
> > joins in. So, I'd guess it sees the first as: do the LOJ and then join
> > that
On Sun, 23 Sep 2001, Stephan Szabo wrote:
> On Sun, 23 Sep 2001, Alex Pilosov wrote:
>
> > It may be just me, or I am grossly misunderstanding syntax of outer joins,
> > but I see that plans for my queries are different depending on how I place
> > join conditions and sometimes even on order of
On Sun, 23 Sep 2001, Alex Pilosov wrote:
> It may be just me, or I am grossly misunderstanding syntax of outer joins,
> but I see that plans for my queries are different depending on how I place
> join conditions and sometimes even on order of the tables.
>
> Example:
> 1:
> explain select * fro
It may be just me, or I am grossly misunderstanding syntax of outer joins,
but I see that plans for my queries are different depending on how I place
join conditions and sometimes even on order of the tables.
Basically, if I mix ANSI-syntax outer joins (a left outer join b on
a.id=b.id) and "wher
Algirdas,
This should do the trick:
SELECT a.id,b.name FROM a,b WHERE a.id=b.id UNION SELECT id,null FROM a WHERE id NOT
IN (SELECT id FROM b);
Troy
>
> Hi all,
>
> I'm new to postgre, I've changed my work and consequently now i'm moving
> from MS plaform.
> In MS SQL there are such constr
I've read that the version 7.1 provides outer join feature. Since I did not
try it yet, I've no more information about it.
> -Message d'origine-
> De: Algirdas Sakmanas [SMTP:[EMAIL PROTECTED]]
> Date: mercredi 4 avril 2001 13:03
> À:[EMAIL PROTECTED]
Hello,
I believe these are supported in 7.1
On Wed, 4 Apr 2001, [iso-8859-4] Algirdas ©akmanas wrote:
>Hi all,
>
>I'm new to postgre, I've changed my work and consequently now i'm moving
>from MS plaform.
>In MS SQL there are such constructs left or right outer join, in postgres
>there are no
Hi all,
I'm new to postgre, I've changed my work and consequently now i'm moving
from MS plaform.
In MS SQL there are such constructs left or right outer join, in postgres
there are no such thing
Can You offer me strategy to make query that selects from table (a) and
joins to it another (b)
on e
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
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 Rohloff" <[EMAIL PROTECTED]> 01.11.2000 09.02 Uhr >>>
>
> select a.col1, b.col2 from a,b
> where a.col1 = b.col2
> or b.col2 is null
>
This query has nothing to do with an outer join. See the following example:
table a
c1
---
x
y
and
table b
c2
---
x
Then an outer join give
>> select a.col1, b.col2 from a,b
>> where a.col1 = b.col2
>>or a.col1 not in (select b.col2 from b)
>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 qu
Marc,
> select a.col1, b.col2 from a,b
> where a.col1 = b.col2
>or b.col2 is null
The above would select each record in a that matched a record in b, plus
each record in b for every possible a where b.col2 was null - not where
there was no match.
> select a.col1, b.col2 from a,b
> where a.
Marc,
I did not look at your queries, but outer joins are supported in the latest
development version of PostgreSQL, and will be supported in the upcoming 7.1 release
of the software - beta due soon.
Regards,
Grant
Marc Rohloff wrote:
> I've been looking at the open-source databases for a pr
I've been looking at the open-source databases for a project I am working on and while
reading about Postgres I saw that they do not support outer joins yet. I was intrigued
by their solution of using a union query.
Something Like:
select a.col1, b.col2 from a,b where a.col1 = b.col2
union
sele
20 matches
Mail list logo
