| 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: | Whole Thread | Raw Message | 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? |