> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> There was more time questions about array's initialisation. I propose
>> function array_init.
>
>> CREATE OR REPLACE FUNCTION array_init(sizes int[], v anyelement)
>> RETURNS anyarray;
>
> I think this is basically a good idea, but maybe the API needs a bit of
> adjustment --- providing the sizes as an array doesn't seem especially
> convenient. Since we only allow up to 6 dimensions (IIRC), what about
> six functions with different numbers of parameters:
>
> array_int(int, anyelement)
> array_int(int, int, anyelement)
> ...
> array_int(int, int, int, int, int, int, anyelement)
>
> I don't object to having the array-input version too, but seems like in
> most cases this way would be easier to use. It wouldn't work well
> for providing lower bounds too, but maybe the array-input case is
> sufficient for that.
Your proposal is maybe little bit readable with lower bounds, and when
initial value is integer. But it's easy do wrap SQL functions .
>
> Other thoughts:
>
> * Should the fill value be the first parameter instead of the last?
> I'm not sure either way.
I am not sure too. I have not any original - the nearest function is memset?
>
> * I have a mild preference for "array_fill" instead of "array_init".
maybe, maybe array_set. Any ideas are welcome
>
> * We can handle a null fill value now, but what about nulls in the
> dimensions? The alternatives seem to be to return a null array
> (not an array of nulls) or throw error.
I am afraid so null array can be changed with null value - so I prefer
in this case raise exception.
Regards
Pavel Stehule
>
> regards, tom lane
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment