Skip site navigation (1) Skip section navigation (2)

Re: Proposal: new function array_init

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: new function array_init
Date: 2008-06-02 16:46:44
Message-ID: 20173.1212425204@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Greg SmithDate: 2008-06-02 16:47:42
Subject: Re: Overhauling GUCS
Previous:From: David E. WheelerDate: 2008-06-02 16:45:27
Subject: Re: Case-Insensitve Text Comparison

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group