Re: Proposal: associative arrays for plpgsql (concept)

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Proposal: associative arrays for plpgsql (concept)
Дата
Msg-id Pine.LNX.4.44.0506292024371.20754-100000@kix.fsv.cvut.cz
обсуждение исходный текст
Ответ на Re: Proposal: associative arrays for plpgsql (concept)  (Douglas McNaught <doug@mcnaught.org>)
Список pgsql-hackers
On Wed, 29 Jun 2005, Douglas McNaught wrote:

> David Fetter <david@fetter.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
 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [PATCHES] Users/Groups -> Roles
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Proposal: associative arrays for plpgsql (concept)