Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION
От | Daniel Farina |
---|---|
Тема | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION |
Дата | |
Msg-id | 429f3b220911231531v6e268b31j593147aacd416767@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH 4/4] Add tests to dblink covering use of COPY TO FUNCTION (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Mon, Nov 23, 2009 at 2:16 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Nov 23, 2009 at 4:34 PM, Daniel Farina <dfarina@truviso.com> wrote: >> Signed-off-by: Daniel Farina <dfarina@truviso.com> > > Thanks for the patch. You may want to take a look at this: > > http://wiki.postgresql.org/wiki/Submitting_a_Patch > > I'm fuzzy on what problem this is attempting to solve... It seems somewhat strange that the only things COPY can do with its output stream of bytes is exactly two modes that are baked into Postgres in the core. This allows carefully written UDFs to do whatever they will with the stream of bytes, such as sending into a waiting libpq connection. > as mentioned in the above guidelines, it's usually good to start with some design > discussions before writing/submitting code. The patch is derived from functionality in the Truviso postgres-derived database product which is non-optional. This is extruded from that. > Also, we prefer that patches be submitted as context diffs I actually remembered this right after I sent it...sorry about that. > And that they not be split up over multiple emails. With the possible exception of squashing together the test cases into their implementing patches, I would say this is at least two patches. One is to a contrib, the other to core PostgreSQL. It so happens the core addition makes the contrib changes much more obviously useful. fdr
В списке pgsql-hackers по дате отправления: