Re: using composite types in insert/update

Sam Mason wrote:
> On Fri, Jan 30, 2009 at 02:47:49PM -0500, Merlin Moncure wrote:
>> On 1/30/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>>> > You are missing the point, using the composite type allows you to
>>> > build the insert without knowing the specific layout of the
>>> > table...
>>>
>>> Surely at *some* level you have to know that.
>> You don't (if I understand your meaning) ...you just have to make sure
>> the destination of the insert is the same as the source.
>
> Sounds as though there are at least two levels that know the specific
> layout of the tables involved then. 1) PG has to know the structure of
> the tables, and 2) you application relies on the fact that tables of the

What merlin is trying to solve is home-grown replication. By
definition, the master and slave must have the same table(s). So I
think he is looking for a more elegant method of performing slave
updates; rather than mirror.field_a=master.field_a,
mirror.field_b=master.field_b, etc... until you are blue in the face.

What makes single field updating even worse is the maintained overhead
involved if the table structure changes; can't just alter the two
tables, you also have to modify the UPDATE statement.

> same name have the same structure. Sounds like a very simple ah-hoc
> nominal type system to me.

No. Its an ad-hoc replication system. A change to UPDATE is needed for
it to work, not a type system.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/