Re: Non-procedural field merging? - Mailing list pgsql-sql

From Richard Huxton
Subject Re: Non-procedural field merging?
Date
Msg-id 002501c07742$a9990aa0$1001a8c0@archonet.com
Whole thread Raw
In response to Non-procedural field merging?  ("Richard Huxton" <dev@archonet.com>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Casting
Next
From: Tom Lane
Date:
Subject: Re: pqReadData()