----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "John Huttley" <John@mwk.co.nz>
Cc: <pgsql-hackers@postgresql.org>
Sent: Thursday, 23 November 2000 19:05
Subject: Re: [HACKERS] Please advise features in 7.1
> "John Huttley" <John@mwk.co.nz> writes:
> > Reason: I want to know if any of these features are scheduled.
>
> > 1. Calculated fields in table definitions . eg.
>
> > Create table test (
> > A Integer,
> > B integer,
> > the_sum As (A+B),
> > );
>
> You can do that now (and for many versions past) with a trigger.
> It's not quite as convenient as it ought to be, but it's possible.
> AFAIK there's no change in that situation for 7.1.
>
Yes, Perhaps defining the table with a dummy field and setting up a
'before'
trigger which replaced that field with a calculated value?
Messy but feasible.
> > 2. Any parameterised triggers
>
> We've had parameterized triggers for years. Maybe you attach some
> meaning to that term beyond what I do?
I'm referring to the manual that says functions used for triggers must have
no parameters
and return a type Opaque. And indeed it is impossible to create a trigger
from a plSQL function that takes any parameters.
Thus if we have a lot of triggers which are very similar, we cannot just use
one function
and pass an identifying parameter or two to it. We must create an
individual function for each trigger.
Its irritating more than fatal.
> > 3. Any parameterised stored procedures that return a result set.
>
> There is some support (dating back to Berkeley Postquel) for functions
> returning sets, but it's pretty ugly and limited. Proper support might
> happen in 7.2 ...
Something to look forward to! Meanwhile I'll have a play and see if its
possible to use a read trigger
to populate a temporary table. hmm, that might require a statement level
trigger. Another thing for 7.2,
i guess.
The application programming we are doing now utilises stored procedures
returning record sets
(MSSQL) and the lack is showstopper in our migration plans. Sigh.
Thanks Tom
Regards
John
