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@sss.pgh.pa.us> wrote:
>>> Merlin Moncure <mmoncure@gmail.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/