Re: using composite types in insert/update - Mailing list pgsql-hackers

From Sam Mason
Subject Re: using composite types in insert/update
Date
Msg-id 20090130205530.GC3008@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: using composite types in insert/update  (Andrew Chernow <ac@esilo.com>)
List pgsql-hackers
On Fri, Jan 30, 2009 at 03:29:29PM -0500, Andrew Chernow wrote:
> 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).

Yes, we know that, but the code doesn't.  I was just being pedantic and
pointing out where the assumptions of this replication rest.

> > 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.

It seems convenient to think about the resulting assumptions as a type
system.  It did to me anyway, but apparently this is causing much
confusion and it was a bad analogy to have drawn.

--  Sam  http://samason.me.uk/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: parallel restore
Next
From: Andrew Dunstan
Date:
Subject: Re: parallel restore