01.10.2018 16:27, Adriano dos Santos Fernandes wrote:
Usage of FETCH seems good here, then I believe the production of rows
would need a YIELD .
Why to invent a new syntax instead of assignment + SUSPEND which everybody
got used to?
--
WBR, SD.
Firebird-Devel mailing list, web
On 30/09/2018 06:25, Dimitry Sibiryakov wrote:
> 30.09.2018 4:52, Adriano dos Santos Fernandes wrote:
>> - Instead of agg_finished, adjust SUSPEND (probably with another
>> keyword) to somehing like: SUSPEND WHEN FETCHED DO WHEN
>> FINISHED DO
>
> Isn't it how FETCH is used to be used:
>
>
On 01/10/2018 10:49, Dimitry Sibiryakov wrote:
> 01.10.2018 15:35, Adriano dos Santos Fernandes wrote:
>> A single (aggregate) function call should not produce (describe) more
>> than one column in a query.
>
> Where is such limitation described except current codebase?
>
>
avg_deviation(x) + 10
01.10.2018 15:35, Adriano dos Santos Fernandes wrote:
A single (aggregate) function call should not produce (describe) more
than one column in a query.
Where is such limitation described except current codebase?
--
WBR, SD.
Firebird-Devel mailing list, web interface at
On 01/10/2018 09:46, Alex Peshkoff via Firebird-devel wrote:
> On 10/01/18 12:44, Dimitry Sibiryakov wrote:
>> 01.10.2018 11:24, Pavel Cisar wrote:
>>> Aggregates could produce various single-value outputs
>>
>> Why to limit them to single value? Some aggregates could profit if
>> they are able
On 10/01/18 12:44, Dimitry Sibiryakov wrote:
01.10.2018 11:24, Pavel Cisar wrote:
Aggregates could produce various single-value outputs
Why to limit them to single value? Some aggregates could profit if
they are able to return more values at once. For example, avg +
deviation.
That
01.10.2018 12:41, Adriano dos Santos Fernandes wrote:
Saying that aggregate functions should return more than one data with a
feature different than ROW type, is like saying our function (and any
language's function) is broken.
No thing is broken. ROW type is just a syntax sugar. But if you
Dimitry Sibiryakov wrote Mon, 01 Oct 2018 13:28:44
+0300:
01.10.2018 12:22, Simonov Denis via Firebird-devel wrote:
Current SPs do not know how to aggregate data by an external cursor. To
do this, you need to write queries inside the SP.
How is this related to (in)ability to return
On 01/10/2018 07:28, Dimitry Sibiryakov wrote:
> 01.10.2018 12:22, Simonov Denis via Firebird-devel wrote:
>> Current SPs do not know how to aggregate data by an external cursor.
>> To do this, you need to write queries inside the SP.
>
> How is this related to (in)ability to return several
01.10.2018 12:22, Simonov Denis via Firebird-devel wrote:
Current SPs do not know how to aggregate data by an external cursor. To do this, you need
to write queries inside the SP.
How is this related to (in)ability to return several values at once?
create aggregate function custom_avg (i
Dimitry Sibiryakov wrote Mon, 01 Oct 2018 13:12:36
+0300:
01.10.2018 12:07, Simonov Denis via Firebird-devel wrote:
To return more than one value you need support for ROW types.
Otherwise, the function still does not extract more than one value.
Current SP can return several values
Adriano dos Santos Fernandes wrote Sat, 29 Sep 2018
22:55:52 +0300:
So SUSPEND in this context is very like JS YIELD with caller doing a
reduce.
I have even thought in use YIELD keyword in this context.
Adriano
The keyword YEILD is more preferable for aggregate functions. At the
01.10.2018 12:07, Simonov Denis via Firebird-devel wrote:
To return more than one value you need support for ROW types. Otherwise, the function
still does not extract more than one value.
Current SP can return several values without any new type.
--
WBR, SD.
Firebird-Devel mailing
Dimitry Sibiryakov wrote Mon, 01 Oct 2018 12:44:58
+0300:
01.10.2018 11:24, Pavel Cisar wrote:
Aggregates could produce various single-value outputs
Why to limit them to single value? Some aggregates could profit if
they are able to return more values at once. For example, avg +
01.10.2018 11:24, Pavel Cisar wrote:
Aggregates could produce various single-value outputs
Why to limit them to single value? Some aggregates could profit if they are able to
return more values at once. For example, avg + deviation.
--
WBR, SD.
Firebird-Devel mailing list, web
Hi,
Aggregate UDF's are nice, but I think it's a mistake to think about them
only in classic COUNT(), AVG(), SUM() etc. context. Why we don't look at
them in more general way?
Aggregates loop over input set and produce single value. Right now we do
UDF-like aggregates inside PSQL SP using
I think four adjustments makes the initial syntax better:
- Allow usage of more than one input parameter. Maybe even zero would be
allowed.
- Instead of have special semantics for empty data source, declare the
constant to be returned for it, say: create aggregate function my_count
returning 0 for
On Sat, Sep 29, 2018, 12:14 Dimitry Sibiryakov wrote:
> 29.09.2018 16:30, Dmitry Yemanov wrote:
> > AFAIU, Adriano's point is more about technology (use stall mode for the
> function request),
> > syntax may be adjusted. We may choose a different keyword, if necessary
> (as a syntax sugar
> >
On Sat, Sep 29, 2018, 10:02 Mark Rotteveel wrote:
>
> > It's also the way modern languages implemented the same concept
> > recently, say JavaScript (ecmascript) and C# with yield.
>
> Do you know of an equivalent example in those languages, because I can't
> easily think of an equivalent
29.09.2018 16:30, Dmitry Yemanov wrote:
AFAIU, Adriano's point is more about technology (use stall mode for the function request),
syntax may be adjusted. We may choose a different keyword, if necessary (as a syntax sugar
for the same BLR verb).
Ok. How simple is this technology from engine
29.09.2018 16:57, Dimitry Sibiryakov wrote:
I don't think that to bring completely new meaning ("pull a row from
set") to existing well-known keyword SUSPEND (used to be "push a row
into result set") is a right way to "integrate".
AFAIU, Adriano's point is more about technology (use stall
29.09.2018 14:32, Adriano dos Santos Fernandes wrote:
The focus is to have a feature well integrated with Firebird others features.
I don't think that to bring completely new meaning ("pull a row from set") to existing
well-known keyword SUSPEND (used to be "push a row into result set") is
On 29-9-2018 14:02, Adriano dos Santos Fernandes wrote:
Mark, saying that an object-based interface is better to store state or
the way to support external routines is disregard how good Firebird
selectable procedures are.
Selectable procedures stores intermediary states in a very elegant
It's incredible small the number of custom aggregate functions overall in
projects, nor I think the focus of this feature is to make others DBMS
users migrate to Firebird due to it, specially considering that their
underlying mechanism are very different than what Firebird has.
The focus is to
29.09.2018 14:02, Adriano dos Santos Fernandes wrote:
My propose is to use the same elegant concept for aggregation. Your example seems much
more confusing. It makes sense thinking on interfaces, but very different from Firebird
way of doing things.
Yes, but being similar to others (PG or
Mark, saying that an object-based interface is better to store state or the
way to support external routines is disregard how good Firebird selectable
procedures are.
Selectable procedures stores intermediary states in a very elegant way.
It's also the way modern languages implemented the same
On 28-9-2018 20:14, Adriano dos Santos Fernandes wrote:
On 28/09/2018 15:04, Leyne, Sean wrote:
-Original Message-
From: Adriano dos Santos Fernandes
Sent: Friday, September 28, 2018 1:55 PM
To: firebird-devel@lists.sourceforge.net
Subject: Re: [Firebird-devel] User-defined aggregate
On 28-9-2018 18:34, Adriano dos Santos Fernandes wrote:
Hi!
I propose creation of user-defined aggregate functions.
Lets initially define the requirements for it:
- It should work with empty data set too, in case of use without GROUP
BY clause: i.e., COUNT results in 0, while most others
On 28/09/2018 15:04, Leyne, Sean wrote:
>
>> -Original Message-
>> From: Adriano dos Santos Fernandes
>> Sent: Friday, September 28, 2018 1:55 PM
>> To: firebird-devel@lists.sourceforge.net
>> Subject: Re: [Firebird-devel] User-defined aggregate functions
> -Original Message-
> From: Adriano dos Santos Fernandes
> Sent: Friday, September 28, 2018 1:55 PM
> To: firebird-devel@lists.sourceforge.net
> Subject: Re: [Firebird-devel] User-defined aggregate functions
>
> On 28/09/2018 14:35, Leyne, Sean wrote:
> &
On 28/09/2018 14:35, Leyne, Sean wrote:
>
> How would this work within a GROUP BY context?
>
> I see how it works within a flat list, but when there are intermediate
> levels, I don't see this working.
>
>
Engine does all the work for groups.
Each group makes the function start - suspend (n
> -- Works as standard AVG.
> create aggregate function custom_avg (i double precision) returns (o double
> precision) as
> declare count integer = 0;
> declare accumulated double precision = 0; begin
> while (not agg_finished)
> do
> begin
> if (i is not null) then
>
28.09.2018 18:34, Adriano dos Santos Fernandes wrote:
Design is open if good alternatives are presented. Initially I think:
Why not simply borrow Oracle concepts as you did with packages?
--
WBR, SD.
Firebird-Devel mailing list, web interface at
33 matches
Mail list logo
