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

Re: Proposal: new function array_init

From: "Webb Sprague" <webb(dot)sprague(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: new function array_init
Date: 2008-06-02 17:18:08
Message-ID: b11ea23c0806021018v5be4edb8v3a8294af766d5d0@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Jun 2, 2008 at 9:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
>> There was more time questions about array's initialisation. I propose
>> function array_init.

As one of the questioners, I will give some short thoughts below.

>> CREATE OR REPLACE FUNCTION array_init(sizes int[], v anyelement)
>> RETURNS anyarray;

+1.  +0 for Pavel's proposed syntax, because it feels better, but also
it scales to N dimensions (we should throw an error obviously if the
input is too big, but we can probably source that size through an
include), I hate functions with more than four arguments, and having
six slightly overloaded functions in the system catalogs seems
annoying.

> * 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 would throw an error, unless there is something that one can do with
a null array (perhaps there is?).

We also might want to consider a resize function, and some other
utilities as long as we are bothering with this.

I am sorry that I can't offer to write these, but I don't have the
time to learn the Postgresql infrastructure to do it.

Thanks for the attention Pavel!

In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2008-06-02 17:29:30
Subject: Re: Case-Insensitve Text Comparison
Previous:From: Simon RiggsDate: 2008-06-02 17:10:44
Subject: Re: Outer joins and equivalence

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