Bruno,
> My suggestion:
> SELECT t3.id, coalesce(t1.name, t2.name), t1.abbreviation,
> coalesce(t1.juris_id, t2.juris_id) from
> (t3 left join t1 using (id)) left join t2 using (id);
Cool! I didn't think of that. I'll give it a try.
-Josh
---(end of broadcast)
Just in case there was some misunderstanding of my suggestion here is
what I had in mind.
Your query:
SELECT t1.id, t1.name, t1.abbreviation, t1.juris_id
FROM t1
UNION ALL
SELECT t2.id, t2.name, NULL, t2.juris_id
FROM t2;
My suggestion:
SELECT t3.id, coalesce(t1.name, t2.name), t1.abbreviation,
Bruno,
> I think you might be able to do this using (one sided) outer joins of the
event
> table to the Case and Trial Group tables. The join rules will need to work
for
> exactly one of the two tables. You probably will want to use case statements
in
> the select list to pick values from the
On Tue, Jul 16, 2002 at 15:42:23 -0700,
Josh Berkus <[EMAIL PROTECTED]> wrote:
>
> Table "events", the largest table in the database, contains event schedule
> listing with 11 attributes and one dependant table as well as recursive
> relationships between events. Each event record can be (a
On Tuesday 16 Jul 2002 11:42 pm, Josh Berkus wrote:
> OK, I guess I'll have to get into detail:
>
[detail on cases and trial-groups]
>
> Thus, I need to relate (in views and queries) each Event to the Union of
> Cases and Trial Groups. I just can't figure out how to do so without the
> database
Bruno,
> This sounds like a design issue. This makes it seem like the events
> should be broken out into their own table and the other two tables
> should get joined with the events table when needed.
>
OK, I guess I'll have to get into detail:
Table "cases" is the database's third largest tab
On Tue, Jul 16, 2002 at 09:36:31 -0700,
Josh Berkus <[EMAIL PROTECTED]> wrote:
> Bruno,
>
> > It wouldn't have to be a dummy table. You could have both sets of
> > data
> > in the same table.
>
> Per my original e-mail, this is not an option.
>
> Basically, the two tables have nothing in co
Bruno,
> It wouldn't have to be a dummy table. You could have both sets of
> data
> in the same table.
Per my original e-mail, this is not an option.
Basically, the two tables have nothing in commmon *except* that events
can be scheduled against either table. Otherwise, the two tables have
On Mon, Jul 15, 2002 at 17:31:24 -0700,
Josh Berkus <[EMAIL PROTECTED]> wrote:
> Stephan,
>
> > We had a discussion recently on -general about this. Right now the
> > planner won't push the conditions down into the arms of the union because
> > noone's been sure under what conditions the optim
On Mon, 15 Jul 2002, Josh Berkus wrote:
> Stephan,
>
> > We had a discussion recently on -general about this. Right now the
> > planner won't push the conditions down into the arms of the union because
> > noone's been sure under what conditions the optimization is safe.
>
> So, if performance i
Stephan,
> We had a discussion recently on -general about this. Right now the
> planner won't push the conditions down into the arms of the union because
> noone's been sure under what conditions the optimization is safe.
So, if performance is horrible with the view, I should use a dummy table
On Mon, 15 Jul 2002, Josh Berkus wrote:
> Folks,
>
> I have two tables which are often browsed together through a UNION view, like:
>
> CREATE VIEW two_tables AS
> SELECT t1.id, t1.name, t1.abbreviation, t1.juris_id
> FROM t1
> UNION ALL
> SELECT t2.id, t2.name, NULL, t2.juris_id
> FROM t2;
>
> T
Folks,
I have two tables which are often browsed together through a UNION view, like:
CREATE VIEW two_tables AS
SELECT t1.id, t1.name, t1.abbreviation, t1.juris_id
FROM t1
UNION ALL
SELECT t2.id, t2.name, NULL, t2.juris_id
FROM t2;
This works fine as a view, since I have made the id's unique be
13 matches
Mail list logo
