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