>
> "Tambet Matiisen" <[EMAIL PROTECTED]> writes:
> > How tough it would be to implement
>
> > CREATE VIEW xxx PARAMETERS (yyy) AS zzz;
>
> > as
>
> > CREATE TYPE xxx;
> > CREATE FUNCTION xxx(yyy) RETURNING SETOF xxx LANGUAGE sql AS 'zzz';
>
> What's the point? It'd be nonstandard anyway,
"Tambet Matiisen" <[EMAIL PROTECTED]> writes:
> How tough it would be to implement
> CREATE VIEW xxx PARAMETERS (yyy) AS zzz;
> as
> CREATE TYPE xxx;
> CREATE FUNCTION xxx(yyy) RETURNING SETOF xxx LANGUAGE sql AS 'zzz';
What's the point? It'd be nonstandard anyway, so just use the function.
...
>
> I wonder if it could be possible to improve CREATE VIEW
> syntax by adding parameters? Something like this:
>
> CREATE VIEW product_sales(date,date) AS
> 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
> bet
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
emembered.
Tambet
> -Original Message-
> From: PFC [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 12, 2005 2:08 PM
> To: Tambet Matiisen; pgsql-sql@postgresql.org
> Subject: Re: [SQL] Parameterized views proposition
>
>
>
> What about using PREPARE ?
>
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
