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 по дате отправления: