Re: Insert or Replace or \copy (bulkload) - Mailing list pgsql-general

From Ow Mun Heng
Subject Re: Insert or Replace or \copy (bulkload)
Date
Msg-id 1187143610.9737.3.camel@neuromancer.home.net
Whole thread Raw
In response to Re: Insert or Replace or \copy (bulkload)  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Responses Re: Insert or Replace or \copy (bulkload)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Tue, 2007-08-14 at 10:16 -0500, Scott Marlowe wrote:
> On 8/14/07, Ow Mun Heng <Ow.Mun.Heng@wdc.com> wrote:
> >
> > In MySql, I was using mysqlimport --replace which essentially provided
> > the means to load data into the DB, while at the same time, would
> > provide the necessary logic to replace the entire row if there was a
> > duplicate instead of dying.

> > Anyway, I found a workaround, but, to me, even though it provides a
> > means to an end, it still looks like it'll end up as a maintenance
> > nightmare each time a table has any additional columns added.
> >
> > Solution is taken from this site:
> >
> > http://www.pointwriter.com/blog/index.php?/archives/6-REPLACE-in-PostgreSQL.html
>
> Example code snipped for brevity
>
> > Can anyone tell me if this won't turn out to be a maintenance nightmare?
> > So, the pertinent question is, is there a better mousetrap available?
>
> I don't see why it would be a maintenance nightmare.  Looks pretty
> much like you just create it and go.  Once it's in place it should
> just work.  There are other ways to skin this particular cat, but that
> one seems as good as any.

That would be true only if I didn't have to (remember to) add a alter
the rule each time a new column is added. At the rate of things, it
might be quite an often procedure. (unless of course, I script it, which
is an idea by itself)

Ps : Is it this list's norm to have the OP/sender in the "to" list and
mailing list on the "CC" list?

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Trigger not working as expected, first row gets a null value
Next
From: Tom Lane
Date:
Subject: Re: Compound Indexes