From: | Scott Chapman <scott_list(at)mischko(dot)com> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: SQL subquery to supply table name? |
Date: | 2002-09-27 02:33:08 |
Message-ID: | 200209261933.08021.scott_list@mischko.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thursday 26 September 2002 06:01 pm, Martijn van Oosterhout wrote:
> I think the basic response is "don't do that". SQL doesn't support queries
> where the tables are not predetermined. The query planner would have a
> terrible time since it would not be able to estimate costs prior to
> execution.
It's too bad for the query planner then! :-) (I'm not a Postgresql guru and I
really don't know what the problem would be if the query planner could not
estimate costs beforehand. Don't take my "It's too bad" comment seriously!)
> Since all your "subtables" are likely to have the same structure, why not
> store them all in one table. Any particular reason?
They don't have the same structure. Similar enough for my purposes but not the
same. In all but two cases where I handle the data from the sub-tables, I
handle columns common to the different tables (so these tables are not
normalized completely but I knew that going in) or I hadle all the data as a
unit. The two places where I handle the data specifically I determine which
type of review it is and direct the user to a different web page to deal with
the specifics.
I can solve this problem by running two queries rather one query with a
subquery but that's not as elegant. I was hoping to find a more elegant
solution based on a sub-query.
Scott
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Chapman | 2002-09-27 02:40:37 | Re: SQL subquery to supply table name? |
Previous Message | Joe Conway | 2002-09-27 01:31:54 | Re: SQL subquery to supply table name? |