On 2005-03-12, Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> You need to expose the columns you want to filter on so that they can
> be used in WHERE clauses.
That doesn't help when you're doing outer joins with additional join
restrictions; the semantics of those can't be converted into additional
>
> > Especially if you would like to put a filter on right side of left
> > join. Consider this query:
> >
> > select p.product_id, coalesce(sum(s.amount), 0)
> > from product p
> > left join sales s on p.product_id = s.product_id and s.date between
> > '2005-01-01' and '2005-01-31' group by
On Sat, Mar 12, 2005 at 13:40:30 +0200,
Tambet Matiisen <[EMAIL PROTECTED]> wrote:
> Hi there!
>
> We use views in our applications a lot, in fact we prefer to have least
> sql at client side. All queries are written as select * from view,
> whenever possible.
>
> But there are queries, which a
Prepared statements are not really what I'm looking for. Prepared
statements only last for the duration of the current database session. I
need "permanent prepared statements", if you prefer. Even this is not
entirely correct, because I don't want the query plan to be remembered.
Tambet
>
What about using PREPARE ?
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Hi there!
We use views in our applications a lot, in fact we prefer to have least
sql at client side. All queries are written as select * from view,
whenever possible.
But there are queries, which are impossible to express as views.
Especially if you would like to put a filter on right side of le
