Re: Insert or Replace or \copy (bulkload)
От | Ow Mun Heng |
---|---|
Тема | Re: Insert or Replace or \copy (bulkload) |
Дата | |
Msg-id | 1187143610.9737.3.camel@neuromancer.home.net обсуждение исходный текст |
Ответ на | Re: Insert or Replace or \copy (bulkload) ("Scott Marlowe" <scott.marlowe@gmail.com>) |
Ответы |
Re: Insert or Replace or \copy (bulkload)
|
Список | 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 по дате отправления: