From: | Joe <dev(at)freedomcircle(dot)net> |
---|---|
To: | Aaron Bono <postgresql(at)aranya(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Repetitive code |
Date: | 2006-06-16 15:12:22 |
Message-ID: | 4492CA56.5020505@freedomcircle.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Aaron Bono wrote:
> I haven't stared at your query as long as you have so I may have missed
> something but it looks like in all the selects you are combining the
> first column in the select is the column you filter on. So the the
> outer query doesn't have to know wiether it is a new or changed row:
>
> SELECT * FROM (
> SELECT created as my_date, topic_id, 0, 0, 0, 0 FROM topic
> WHERE page_type IN (1, 2)
> UNION
> [snip]
> SELECT e.updated as my_date, e.topic_id, 1, 1, entry_id, rel_type
> FROM topic_entry e, topic t
> WHERE e.topic_id = t.topic_id
> AND date_trunc('day', e.updated) != e.created
> AND page_type IN (1, 2)
> ) my_union
> where my_union.my_date >= $dt
Thanks Aaron. That does look like a great solution, overlooked since
I'm not that familiar with SELECTs in the FROM clause. It may even make
it possible to discard the interim table and do the web page/RSS feed
directly from the view.
> I would almost be tempted to create a view for each small query and name
> them something meaningful and then another view that does the union. It
> would make the queries easier to understand at least (self documented).
That sounds like a good idea too because schema changes would be
somewhat insulated by the layered views.
Best regards,
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-06-16 15:57:13 | Re: Repetitive code |
Previous Message | Aaron Bono | 2006-06-16 14:44:42 | Re: Repetitive code |