Re: Proposal: new function array_init - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: new function array_init
Date
Msg-id 20173.1212425204@sss.pgh.pa.us
Whole thread Raw
In response to Proposal: new function array_init  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Responses Re: Proposal: new function array_init  ("Webb Sprague" <webb.sprague@gmail.com>)
Re: Proposal: new function array_init  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Re: Proposal: new function array_init  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
"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.

Other thoughts:

* Should the fill value be the first parameter instead of the last?
I'm not sure either way.

* I have a mild preference for "array_fill" instead of "array_init".

* 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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Case-Insensitve Text Comparison
Next
From: Greg Smith
Date:
Subject: Re: Overhauling GUCS