| From: | Michael Glaesemann <grzm(at)seespotcode(dot)net> |
|---|---|
| To: | Decibel! <decibel(at)decibel(dot)org> |
| Cc: | Jeremy Drake <pgsql(at)jdrake(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [mmoncure@gmail.com: Re: [GENERAL] array_to_set functions] |
| Date: | 2007-08-08 17:03:34 |
| Message-ID: | 29453D07-814B-4375-B4F2-43E2C1E867DB@seespotcode.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Decibel! | 2007-08-08 17:07:19 | Re: GUC for default heap fillfactor |
| Previous Message | Decibel! | 2007-08-08 17:00:47 | Re: HOT patch, missing things |