Re: [mmoncure@gmail.com: Re: [GENERAL] array_to_set functions] - Mailing list pgsql-hackers

From Michael Glaesemann
Subject Re: [mmoncure@gmail.com: Re: [GENERAL] array_to_set functions]
Date
Msg-id 29453D07-814B-4375-B4F2-43E2C1E867DB@seespotcode.net
Whole thread Raw
In response to Re: [mmoncure@gmail.com: Re: [GENERAL] array_to_set functions]  (Decibel! <decibel@decibel.org>)
Responses Re: [mmoncure@gmail.com: Re: [GENERAL] array_to_set functions]  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
On Aug 8, 2007, at 11:41 , Decibel! wrote:

> On Tue, Aug 07, 2007 at 10:18:32PM -0700, Jeremy Drake wrote:

>> select * from information_schema._pg_expandarray(ARRAY['foo',  
>> 'bar', 'baz']);
>>   x  | n
>> -----+---
>>  foo | 1
>>  bar | 2
>>  baz | 3
>> (3 rows)
>>
>> Not exactly well documented or well known, but it works.
>
> Worse than that, that's something that's entirely internal and could
> change at any release. The fact that it exists for info_schema  
> indicates
> further need for these functions to exist in the backend.

Personally, I think expandarray is more appropriate and its  
functionality probably more generally useful, as it identifies the  
array indices as well. Note you can also rename the columns.

select * from information_schema._pg_expandarray(ARRAY['foo', 'bar',  
'baz']) as b(a,i);  a  | i
-----+---
foo | 1
bar | 2
baz | 3
(3 rows)

array_to_set really isn't, as AFAICS it didn't guarantee element  
uniqueness (but that's just a naming issue).

Michael Glaesemann
grzm seespotcode net



pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: HOT patch, missing things
Next
From: Decibel!
Date:
Subject: Re: GUC for default heap fillfactor