From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <rbt(at)zort(dot)ca> |
Cc: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: insert with multiple targetLists |
Date: | 2002-06-02 05:53:11 |
Message-ID: | 200206020553.g525rBK11268@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Rod Taylor wrote:
> > INSERT INTO t1 (c1) VALUES (1), (2);
> >
> > would be executed in a similar fashion to:
> >
> > INSERT INTO t1 (c1) VALUES (1);
> > INSERT INTO t1 (c1) VALUES (2);
> >
> > Does this sound reasonable?
Sounds good to me.
> I debated doing the above too. In fact, I had a partial
> implementation at one point.
>
> However, the resulting purpose of allowing such a construct is to
> enable the speeds copy achieves with the variation that is found in an
> insert. ...
I thought the purpose of the item was merely for compatibility with
other databases that support this syntax. I don't think it will ever
match COPY performance, and I don't think stuffing a huge INSERT into
the database rather than COPY rows will ever be a preferred method.
I only see VALUES used by INSERT so if you can think of a clean way to
make that work as multiple INSERTs, I think it would be a good idea.
Hopefully, it will be one localized change, and we can remove it if we
ever want to support VALUES in more complex situations, as Tom
mentioned.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-06-02 06:09:25 | Re: Search from newer tuples first, vs older tuples first? |
Previous Message | Peter Eisentraut | 2002-06-01 20:58:15 | Re: wierd AND condition evaluation for plpgsql |