Re: Array aggregation. Was: PostgreSQL Final Release ... Monday? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Array aggregation. Was: PostgreSQL Final Release ... Monday?
Date
Msg-id 13500.1012603612@sss.pgh.pa.us
Whole thread Raw
In response to Array aggregation. Was: PostgreSQL Final Release ... Monday?  (Hannu Krosing <hannu@krosing.net>)
List pgsql-hackers
Hannu Krosing <hannu@krosing.net> writes:
> 2. Is there a way to define a function such that

>   declare make_array(any) returns any[] ?

No.  We do need a way to construct an array as an expression result,
but I think it will have to be a special syntactic case, not an ordinary
function.  Maybe something roughly like a CAST construct,ARRAY(expr,expr,expr,... OF type-name)

The function definition language isn't nearly powerful enough to deal
with this --- heck, we don't even support a variable number of
arguments.  If it were, it'd probably break the whole ambiguous-
function-call resolution mechanism --- what type do you assign to the
output if you're not entirely sure how the inputs are to be interpreted?

> 3. Also, can I prescribe order of aggregation (aggregation applied
>    _after_ ORDER BY) that would act in a way similar to HAVING .

Sub-select in FROM might help here.

> 4. what arguments must I give to array_in so that it produces an 
>    array of specific kind ?

You don't.  array_in is meant to be used as the declared typinput
routine for an array type; that linkage is what causes the system
to know what the output array type is.  array_in by itself can't
cause the system to assign a correct type to its result.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: The " \! " and " \l " commands
Next
From: Bruce Momjian
Date:
Subject: Re: Syscaches should store negative entries, too