Re: COPY FROM WHEN condition
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>,
Surafel Temesgen <surafel3000@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Adam Berlin <berlin.ab@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Haribabu Kommi <kommi.haribabu@gmail.com>
Date: 2019-04-04T13:41:42Z
Lists: pgsql-hackers
On Thu, 4 Apr 2019 at 18:20, Andres Freund <andres@anarazel.de> wrote: > I'm pretty happy with this. I'm doing some minor changes (e.g. don't > like the function comment formatting that much, the tableam callback > needs docs, stuff like that), and then I'm going to push it tomorrow. > > I'm planning to attribute it to you, me, and Haribabu Kommi. Sounds good. > > Oh, btw, is there a reason you're memset(0)'ing multiInsertInfo? Seems > unnecessary, given that in all cases we're using it we're going to do > CopyMultiInsertInfo_Init(). And IME valgrind and the compiler are more > helpful when you don't just default initialize, because then they can > tell when you forgot to initialize a field (say like > CopyMultiInsertInfo_Init not initializing nbuffers). At some point when I was hacking at it, I was getting a warning about it being possibly uninitialised. I don't recall exactly how the code was then, but I just tried removing it and I don't get any warning now. So probably fine to remove. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Remove unused struct member, enforce multi_insert callback presence.
- 57a7a3adfe4e 12.0 landed
-
Separate per-batch and per-tuple memory contexts in COPY
- 36a1281f86c0 12.0 landed
-
Fix handling of volatile expressions in COPY FROM ... WHERE
- 4a8283d0ec5a 12.0 landed
-
Allow COPY FROM to filter data using WHERE conditions
- 31f3817402da 12.0 landed
-
Remove obsolete netbsd dynloader code
- b68ff3ea672c 12.0 cited