Re: using composite types in insert/update
От | Sam Mason |
---|---|
Тема | Re: using composite types in insert/update |
Дата | |
Msg-id | 20090130205530.GC3008@frubble.xen.chris-lamb.co.uk обсуждение исходный текст |
Ответ на | Re: using composite types in insert/update (Andrew Chernow <ac@esilo.com>) |
Список | 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 по дате отправления: