Re: Proposal: new function array_init
От | Pavel Stehule |
---|---|
Тема | Re: Proposal: new function array_init |
Дата | |
Msg-id | 162867790806021110n33d6bf54l97e57304ec97157f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: new function array_init (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal: new function array_init
|
Список | pgsql-hackers |
2008/6/2 Tom Lane <tgl@sss.pgh.pa.us>: > "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 >
В списке pgsql-hackers по дате отправления: