Re: Non-procedural field merging?

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: Non-procedural field merging?
Дата
Msg-id 002501c07742$a9990aa0$1001a8c0@archonet.com
обсуждение исходный текст
Ответ на Non-procedural field merging?  ("Richard Huxton" <dev@archonet.com>)
Список pgsql-sql
From: "Tom Lane" <tgl@sss.pgh.pa.us>

[snipped my Q about merging text fields from one table into another]

> You could do it with a user-defined aggregate function (initial
> value '' and transition function ||).  I am not sure that aggregates
> work in an intelligent way in UPDATE --- ie, I am not sure it would
> work to do
>
> update foo2 set d = catenate(foo.b) from foo where foo.a=foo2.c;

Actually, (to my surprise) it did work. I used:

richardh=> create aggregate catenate(sfunc1=textcat, basetype=text,
stype1=text, initcond1='');
CREATE
richardh=> select a,catenate(b) from foo group by a;a | catenate
---+----------1 | xxxyyy
(1 row)

Then tried the update - worked with no problem, noting that:

richardh=> update foo2 set d = catenate(foo.b) from foo where foo.a=foo2.c;
UPDATE 1
richardh=> select * from foo2;c |   d
---+--------1 | yyyxxx
(1 row)

The order is reversed between the select and the update! Important lesson in
the relationship between SQL and set theory noted (my college lecturers
would be proud of me ;-)

> I seem to recall some discussion concluding that that didn't have
> very well-defined semantics.

I can see how you'd have problems if you were expecting the aggregate to
return the same value on each run (a vacuum presumably could reorder the
values). In my case, this isn't important.

I must admit it didn't occur to me you could create your own aggregates
without resorting to C. Shame it's not a standard SQL feature.

Thanks Tom - don't know how you find the time to give so much help in the
lists.

- Richard Huxton



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Casting
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pqReadData()