From: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> |
---|---|
To: | Douglas McNaught <doug(at)mcnaught(dot)org> |
Cc: | David Fetter <david(at)fetter(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: associative arrays for plpgsql (concept) |
Date: | 2005-06-29 18:36:37 |
Message-ID: | Pine.LNX.4.44.0506292024371.20754-100000@kix.fsv.cvut.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 29 Jun 2005, Douglas McNaught wrote:
> David Fetter <david(at)fetter(dot)org> writes:
>
> > I'm all in favor of having associative arrays as a 1st-class data type
> > in PostgreSQL. How much harder would it be to make these generally
> > available vs. tied to one particular language?
>
> We already have them--they're called "tables with primary keys". :)
>
> What's the use-case for these things? Just imitating Oracle?
>
> -Doug
>
no
for example
DECLARE _d varchar[] INDEX BY VARCHAR = {'cmd1' => '723:t:f:1', 'cmd2'=>..
BEGIN
FOR r IN SELECT * FROM data LOOP
check_params(_r, _d[_r.cmd])
END LOOP;
or without assoc. arrays
DECLARE _d varchar;
BEGIN
FOR r IN SELECT * FROM data LOOP
SELECT INTO par _d WHERE cmd = _r.cmd;
check_params(_r, _d)
END LOOP;
I can't to speak about speed without tests but I can expect so hash array
can be much faster. This sample is easy, but I can have procedure witch
operate over big arrays of numbers(prices) and I need save somewhere this
arrays if I don't wont to read them again and again. And if I have in
data identification by key, I everytime have to find key, and translate it
into number
Regards
Pavel Stehule
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2005-06-29 18:36:51 | Re: [PATCHES] Users/Groups -> Roles |
Previous Message | Pavel Stehule | 2005-06-29 18:24:24 | Re: Proposal: associative arrays for plpgsql (concept) |