Hi,
I've updated the patch set. See the attached v40 patch set.
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 23 Apr 2025 23:44:55 -0700,
Masahiko Sawada wrote:
>> Are the followings correct?
>>
>> 1. Move invalid
On Fri, Apr 4, 2025 at 1:38 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 31 Mar 2025 12:35:23 -0700,
> Masahiko Sawada wrote:
>
> > Most of the queries under test_copy_fo
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sun, 6 Apr 2025 19:29:46 +0800,
jian he wrote:
> I did a brief review of v39-0001 and v39-0002.
>
> text:
> COPY_FILE
> COPY_FRONTEND
> still appear on comments in copy
On Sun, Apr 6, 2025 at 4:30 AM jian he wrote:
>
> CREATE FUNCTION test_copy_format(internal)
> RETURNS copy_handler
> AS 'MODULE_PATHNAME', 'test_copy_format'
> LANGUAGE C;
> src/backend/commands/copy.c: ProcessCopyOptions
> if (strcmp(fmt, "text") == 0)
>
On Thu, Mar 27, 2025 at 11:29 AM Sutou Kouhei wrote:
> We can merge 0001 quickly, right?
I did a brief review of v39-0001 and v39-0002.
text:
COPY_FILE
COPY_FRONTEND
still appear on comments in copyfrom_internal.h and copyto.c,
Should it be removed?
+#include "commands/copyto_internal.h"
#incl
On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei wrote:
>
> > We need more regression tests for handling the given format name. For
> > example,
> >
> > - more various input patterns.
> > - a function with the specified format name exists but it returns an
> > unexpected Node.
> > - looking for a han
On Sat, Mar 29, 2025 at 1:57 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 28 Mar 2025 22:37:03 -0700,
> Masahiko Sawada wrote:
>
> >> I've added the following tes
On Sat, Mar 29, 2025 at 9:49 AM David G. Johnston
wrote:
>
> On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei wrote:
>>
>>
>> The attached v39 patch set uses the followings:
>>
>> 0001: Create copyto_internal.h and change COPY_XXX to
>> COPY_SOURCE_XXX and COPY_DEST_XXX accordingly.
>> (S
On Friday, March 28, 2025, Masahiko Sawada wrote:
>
>
> One problem in the following chunk I can see is:
>
> + qualified_format = stringToQualifiedNameList(format, NULL);
> + DeconstructQualifiedName(qualified_format, &schema, &fmt);
> + if (!schema || strcmp(schema,
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 31 Mar 2025 12:35:23 -0700,
Masahiko Sawada wrote:
> Most of the queries under test_copy_format/sql verifies the input
> patterns of the FORMAT option. I find that the regression tes
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 31 Mar 2025 10:05:34 -0700,
"David G. Johnston" wrote:
> The CopyFromInFunc API allows for each attribute to somehow
> have its I/O format individualized. B
On Mon, Mar 31, 2025 at 11:52 AM Masahiko Sawada
wrote:
> On Sat, Mar 29, 2025 at 9:49 AM David G. Johnston
> wrote:
> >
> > On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei wrote:
> >>
> >>
> >> The attached v39 patch set uses the followings:
> >>
> >> 0001: Create copyto_internal.h and change COP
On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei wrote:
>
> > ---
> > +static const CopyFromRoutine CopyFromRoutineTestCopyFormat = {
> > +.type = T_CopyFromRoutine,
> > +.CopyFromInFunc = CopyFromInFunc,
> > +.CopyFromStart = CopyFromStart,
> > +.CopyFromOneRow = Copy
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 29 Mar 2025 09:48:22 -0700,
"David G. Johnston" wrote:
> I don't think this module should be responsible for testing the validity of
> "qualified names in a strin
On Wed, Mar 26, 2025 at 8:28 PM Sutou Kouhei wrote:
>
> The attached v39 patch set uses the followings:
>
> 0001: Create copyto_internal.h and change COPY_XXX to
> COPY_SOURCE_XXX and COPY_DEST_XXX accordingly.
> (Same as 1. in your suggestion)
> 0002: Support custom format for both C
On Sat, Mar 29, 2025 at 1:57 AM Sutou Kouhei wrote:
> * I still think that someone may don't like defining COPY
> handlers for built-in formats. If we don't define COPY
> handlers for built-in formats finally, we can just drop
> 0004.
>
We should (and usually do) dog-food APIs when reason
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 28 Mar 2025 22:37:03 -0700,
Masahiko Sawada wrote:
>> I've added the following tests:
>>
>> * Wrong input type handler without namespace
>> * Wrong input type h
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sun, 23 Mar 2025 02:01:59 -0700,
Masahiko Sawada wrote:
> ---
> +/*
> + * Process the "format" option.
> + *
> + * This function checks whether the option value is a
On Wed, Mar 19, 2025 at 6:25 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 19 Mar 2025 17:49:49 -0700,
> "David G. Johnston" wrote:
>
> >> And could someone
On Wed, Mar 19, 2025 at 6:25 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 19 Mar 2025 17:49:49 -0700,
> "David G. Johnston" wrote:
>
> >> And could someone
On Fri, Mar 21, 2025 at 10:23 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Then this would benefit from the new function I suggest creating since it
> apparently has the same, IMO, bug.
>
>
Concretely like I posted here:
https://www.postgresql.org/message-id/cakfquwybtck+uw-byfchhp8
On Friday, March 21, 2025, Masahiko Sawada wrote:
> On Fri, Mar 21, 2025 at 5:32 PM David G. Johnston
> wrote:
> >
> > On Tue, Mar 18, 2025 at 7:56 PM Sutou Kouhei wrote:
> >>
> >> Hi,
> >>
> >> In
> >> "Re: Make COPY for
On Fri, Mar 21, 2025 at 5:32 PM David G. Johnston
wrote:
>
> On Tue, Mar 18, 2025 at 7:56 PM Sutou Kouhei wrote:
>>
>> Hi,
>>
>> In
>> "Re: Make COPY format extendable: Extract COPY TO format implementations"
>> on Mon, 17 Mar 2025 13:50:03
On Tue, Mar 18, 2025 at 7:56 PM Sutou Kouhei wrote:
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format
> implementations" on Mon, 17 Mar 2025 13:50:03 -0700,
> Masahiko Sawada wrote:
>
> > I think that built-in formats also nee
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 19 Mar 2025 17:49:49 -0700,
"David G. Johnston" wrote:
>> And could someone help (take over if possible) writing a
>> document for this feature? I'm not goo
On Tue, Mar 18, 2025 at 7:56 PM Sutou Kouhei wrote:
> And could someone help (take over if possible) writing a
> document for this feature? I'm not good at writing a
> document in English... 0009 in the attached v37 patch set
> has a draft of it. It's based on existing documents in
> doc/src/sgml
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 17 Mar 2025 13:50:03 -0700,
Masahiko Sawada wrote:
> I think that built-in formats also need to have their handler
> functions. This seems to be a conventional way for customizable
&g
On Tue, Mar 4, 2025 at 4:06 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 3 Mar 2025 11:06:39 -0800,
> Masahiko Sawada wrote:
>
> > I agree with the fix and the patch looks
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 3 Mar 2025 11:06:39 -0800,
Masahiko Sawada wrote:
> I agree with the fix and the patch looks good to me. I've updated the
> commit message and am going to push, barring any objec
On Sun, Mar 2, 2025 at 4:19 PM Sutou Kouhei wrote:
>
> Hi,
>
> In <3191030.1740932...@sss.pgh.pa.us>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Sun, 02 Mar 2025 11:27:20 -0500,
> Tom Lane wrote:
>
> >> W
On Mon, Mar 3, 2025 at 8:19 AM Sutou Kouhei wrote:
>
> Hi,
>
> In <3191030.1740932...@sss.pgh.pa.us>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Sun, 02 Mar 2025 11:27:20 -0500,
> Tom Lane wrote:
>
> >> W
Hi,
In <3191030.1740932...@sss.pgh.pa.us>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sun, 02 Mar 2025 11:27:20 -0500,
Tom Lane wrote:
>> While review another thread (Emitting JSON to file using COPY TO),
>> I found the recent
Junwang Zhao writes:
> While review another thread (Emitting JSON to file using COPY TO),
> I found the recently committed patches on this thread pass the
> CopyFormatOptions struct directly rather a pointer of the struct
> as a function parameter of CopyToGetRoutine and CopyFromGetRoutine.
Cover
On Sat, Mar 1, 2025 at 10:50 AM Sutou Kouhei wrote:
>
> Hi,
>
> Our 0001/0002 patches were merged into master. I've rebased
> on master. Can we discuss how to proceed rest patches?
>
> The contents of them aren't changed but I'll show a summary
> of them again:
>
> 0001-0003 are for COPY TO and 00
Hi,
Our 0001/0002 patches were merged into master. I've rebased
on master. Can we discuss how to proceed rest patches?
The contents of them aren't changed but I'll show a summary
of them again:
0001-0003 are for COPY TO and 0004-0007 are for COPY FROM.
For COPY TO:
0001: Add support for adding
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 28 Feb 2025 14:00:18 -0800,
Masahiko Sawada wrote:
> Yes, I've submitted the patch to re-export that function[1]. Could you
> review it?
>
> [1]
> https:/
On Fri, Feb 28, 2025 at 1:58 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 28 Feb 2025 11:50:39 -0800,
> Masahiko Sawada wrote:
>
> > I initially thought it would be acce
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 28 Feb 2025 11:50:39 -0800,
Masahiko Sawada wrote:
> I initially thought it would be acceptable to stop
> NextCopyFromRawFields exposed since NextCopyFrom() could serve as an
&g
On Thu, Feb 27, 2025 at 7:57 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Thu, 27 Feb 2025 15:24:26 -0800,
> Masahiko Sawada wrote:
>
> > Pushed the 0001 patch.
>
> Than
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 27 Feb 2025 15:24:26 -0800,
Masahiko Sawada wrote:
> Pushed the 0001 patch.
Thanks!
> Regarding the 0002 patch, I realized we stopped exposing
> NextCopyFromRawFields() functi
On Tue, Feb 25, 2025 at 6:08 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 25 Feb 2025 17:14:43 -0800,
> Masahiko Sawada wrote:
>
> > I've attached updated patches.
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 25 Feb 2025 17:14:43 -0800,
Masahiko Sawada wrote:
> I've attached updated patches.
Thanks.
I found one more missing last ".":
0002:
> --- a/src/backend/commands
On Tue, Feb 25, 2025 at 3:52 PM Sutou Kouhei wrote:
>
>
Thank you for reviewing the patches. I've addressed comments except
for the following comment:
> > --- a/src/backend/commands/copyfromparse.c
> > +++ b/src/backend/commands/copyfromparse.c
>
> > @@ -1087,7 +1132,7 @@ NextCopyFrom(CopyFromSt
On Thu, Feb 20, 2025 at 6:48 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Thu, 20 Feb 2025 15:28:26 -0800,
> Masahiko Sawada wrote:
>
> > Looking at the 0001
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 25 Feb 2025 14:05:28 -0800,
Masahiko Sawada wrote:
> The first two patches are refactoring patches (+ small performance
> improvements). I've reviewed these patches again and a
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 20 Feb 2025 15:28:26 -0800,
Masahiko Sawada wrote:
> Looking at the 0001 patch again, I have a question: we have
> CopyToTextLikeOneRow() for both CSV and text format:
>
> +/*
On Fri, Feb 7, 2025 at 5:01 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 4 Feb 2025 22:20:51 -0800,
> Masahiko Sawada wrote:
>
> >> I was just looking at bit at this
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 4 Feb 2025 22:20:51 -0800,
Masahiko Sawada wrote:
>> I was just looking at bit at this series of patch labelled with v31,
>> to see what is happening here.
>&
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 5 Feb 2025 12:29:44 -0800,
Masahiko Sawada wrote:
>> It seems that
>> FmgrInfo doesn't have return value type information. Should
>> we read pg_catalog.pg_proc or some
On Tue, Feb 4, 2025 at 11:37 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 4 Feb 2025 17:32:07 -0800,
> Masahiko Sawada wrote:
>
> > BTW we need to check if the return v
On 2025-Feb-05, Masahiko Sawada wrote:
> I think that the patch needs to check if the function's result type is
> COPY_HANDLEROID by using get_func_rettype(), before calling it. But
> with this check, we can prevent arbitrary functions from being called
> via COPY. Why do we need to extend CREATE
On Wed, Feb 5, 2025 at 3:49 AM Álvaro Herrera wrote:
>
> On 2025-Feb-03, Vladlen Popolitov wrote:
>
> > You use FORMAT option to add new formats, filling it with routine name
> > in shared library. As result any caller can call any routine in PostgreSQL
> > kernel.
> > I think, it will start compe
Álvaro Herrera писал(а) 2025-02-05 18:49:
On 2025-Feb-03, Vladlen Popolitov wrote:
You use FORMAT option to add new formats, filling it with routine name
in shared library. As result any caller can call any routine in
PostgreSQL
kernel.
I think, it will start competition, who can find most da
On 2025-Feb-03, Vladlen Popolitov wrote:
> You use FORMAT option to add new formats, filling it with routine name
> in shared library. As result any caller can call any routine in PostgreSQL
> kernel.
> I think, it will start competition, who can find most dangerous routine
> to call just from COP
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 4 Feb 2025 17:32:07 -0800,
Masahiko Sawada wrote:
> BTW we need to check if the return value type of the handler function
> is copy_handler.
Oh, can we do it without calling a functio
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 04 Feb 2025 17:46:10 +0700,
Vladlen Popolitov wrote:
> I think, in case of USING PostgreSQL kernel will call corresponding
> handler,
> and it looks secure - the same as for tabl
On Tue, Feb 4, 2025 at 9:10 PM Michael Paquier wrote:
>
> On Sat, Feb 01, 2025 at 07:12:01PM +0900, Sutou Kouhei wrote:
> > For the propose, copyapi.h should not include
> > copy{to,from}_internal.h. If we do it, copyto.c includes
> > CopyFromState and copyfrom*.c include CopyToState.
> >
> > What
On Tue, Feb 4, 2025 at 6:19 PM Vladlen Popolitov
wrote:
>
> Masahiko Sawada писал(а) 2025-02-05 08:32:
> > On Tue, Feb 4, 2025 at 2:46 AM Vladlen Popolitov
>
> >> >> Standard PostgreSQL realisation for new methods to use USING
> >> >> keyword. Every
> >> >> new method could have own options (FOR
On Sat, Feb 01, 2025 at 07:12:01PM +0900, Sutou Kouhei wrote:
> For the propose, copyapi.h should not include
> copy{to,from}_internal.h. If we do it, copyto.c includes
> CopyFromState and copyfrom*.c include CopyToState.
>
> What do you think about the following change? Note that
> extensions mus
Masahiko Sawada писал(а) 2025-02-05 08:32:
On Tue, Feb 4, 2025 at 2:46 AM Vladlen Popolitov
>> Standard PostgreSQL realisation for new methods to use USING
>> keyword. Every
>> new method could have own options (FORMAT is option of internal 'copy
>> from/to'
>> methods),
>
> Ah, I didn't thi
On Tue, Feb 4, 2025 at 2:46 AM Vladlen Popolitov
wrote:
>
> Sutou Kouhei писал(а) 2025-02-04 13:29:
> Hi
> > Hi,
> >
> > In
> > "Re: Make COPY format extendable: Extract COPY TO format
> > implementations" on Mon, 03 Feb 2025 13:38:04 +0700,
Sutou Kouhei писал(а) 2025-02-04 13:29:
Hi
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format
implementations" on Mon, 03 Feb 2025 13:38:04 +0700,
Vladlen Popolitov wrote:
I would like to inform about the security breach in your design of
COPY TO/FROM.
Thanks
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 03 Feb 2025 13:38:04 +0700,
Vladlen Popolitov wrote:
> I would like to inform about the security breach in your design of
> COPY TO/FROM.
Thanks! I didn't notice it.
> You
Sutou Kouhei писал(а) 2025-02-01 17:12:
Hi,
Hi
I would like to inform about the security breach in your design of COPY
TO/FROM.
You use FORMAT option to add new formats, filling it with routine name
in shared library. As result any caller can call any routine in
PostgreSQL kernel.
I think
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 31 Jan 2025 16:34:52 -0800,
Masahiko Sawada wrote:
> Again, what I'd like to avoid is that we end up adding everything
> (including new fields we add in the future) related t
On Fri, Jan 31, 2025 at 3:10 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 31 Jan 2025 14:25:34 -0800,
> Masahiko Sawada wrote:
>
> > I think that CopyToState and CopyFrom
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 31 Jan 2025 14:25:34 -0800,
Masahiko Sawada wrote:
> I think that CopyToState and CopyFromState are not APIs but the
> execution states. I'm not against exposing CopyToState and
On Thu, Jan 30, 2025 at 7:42 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 28 Jan 2025 15:00:03 -0800,
> Masahiko Sawada wrote:
>
> > While 0001 and 0002 look goo
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 28 Jan 2025 15:00:03 -0800,
Masahiko Sawada wrote:
> While 0001 and 0002 look good to me overall, we still need to polish
> subsequent patches. Here are review comments:
I attached t
On Thu, Jan 23, 2025 at 1:12 AM Sutou Kouhei wrote:
>
> Hi,
>
> I noticed that the last patch set (v27) can't be applied to
> the current master. I've rebased on the current master and
> created v28 patch set. No code change.
Thank you for updating the patch!
While 0001 and 0002 look good to me
Hi,
I noticed that the last patch set (v27) can't be applied to
the current master. I've rebased on the current master and
created v28 patch set. No code change.
Thanks,
--
kou
>From 016ccfc63d2faa441a6996e3dcfd3cdbff7c185f Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Sat, 28 Sep 2024 23:
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 29 Nov 2024 10:15:04 +0800,
Junwang Zhao wrote:
> This thread and [1] thread are kind of interleaved, I chose this thread
> to share the numbers because I think this feature sho
On Fri, Nov 29, 2024 at 9:07 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Thu, 28 Nov 2024 19:02:57 +0800,
> Junwang Zhao wrote:
>
> >> > I tested 3 branches:
> &
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 28 Nov 2024 19:02:57 +0800,
Junwang Zhao wrote:
>> > I tested 3 branches:
>> >
>> > 1. the master branch
>> > 2. all v26 patch sets applied
>> >
On Thu, Nov 28, 2024 at 2:16 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 27 Nov 2024 19:49:17 +0800,
> Junwang Zhao wrote:
>
> > I just gave this another round of bench
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 27 Nov 2024 19:49:17 +0800,
Junwang Zhao wrote:
> I just gave this another round of benchmarking tests. I'd like to
> share the number,
> since COPY TO has some performance dra
Hi,
On Mon, Nov 25, 2024 at 2:02 PM Sutou Kouhei wrote:
>
> Hi,
>
> In <20241125.110620.313152541320718947@clear-code.com>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 25 Nov 2024 11:06:20 +0900 (JST),
> Suto
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 25 Nov 2024 23:10:50 -0800,
Masahiko Sawada wrote:
>> Custom COPY format extensions need to use
>> CopyToStateData/CopyFromStateData. For example,
>> CopyToStateData::r
On Sun, Nov 24, 2024 at 6:06 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 22 Nov 2024 13:01:06 -0800,
> Masahiko Sawada wrote:
>
> >> @@ -1237,7 +1219,7 @@ Cop
Hi,
In <20241125.110620.313152541320718947@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 25 Nov 2024 11:06:20 +0900 (JST),
Sutou Kouhei wrote:
>> I've attached the v25 patches that squashed the minor c
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 22 Nov 2024 13:01:06 -0800,
Masahiko Sawada wrote:
>> @@ -1237,7 +1219,7 @@ CopyReadLine(CopyFromState cstate, bool is_csv)
>> /*
>> * CopyReadLineText - inner loop o
On Wed, Nov 20, 2024 at 6:55 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Wed, 20 Nov 2024 14:14:27 -0800,
> Masahiko Sawada wrote:
>
> > I've extracted the chang
On Thu, Nov 21, 2024 at 2:41 AM Alvaro Herrera wrote:
>
> I ran `make headerscheck` after these patches and it reported a few
> problems:
>
> /pgsql/source/master/src/tools/pginclude/headerscheck /pgsql/source/master
> /pgsql/build/master
> In file included from /tmp/headerscheck.xdG40Y/test.c:2:
I ran `make headerscheck` after these patches and it reported a few
problems:
/pgsql/source/master/src/tools/pginclude/headerscheck /pgsql/source/master
/pgsql/build/master
In file included from /tmp/headerscheck.xdG40Y/test.c:2:
/pgsql/source/master/src/include/commands/copyapi.h:76:44: error: u
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 20 Nov 2024 14:14:27 -0800,
Masahiko Sawada wrote:
> I've extracted the changes to refactor COPY TO/FROM to use the format
> callback routines from v23 patch set, which seems
On Mon, Nov 18, 2024 at 8:44 PM Masahiko Sawada wrote:
>
> On Mon, Nov 18, 2024 at 5:31 PM Sutou Kouhei wrote:
> >
> > Hi,
> >
> > In
> > "Re: Make COPY format extendable: Extract COPY TO format implementations"
> > on Mon, 18 N
On Mon, Nov 18, 2024 at 5:31 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 18 Nov 2024 17:02:41 -0800,
> Masahiko Sawada wrote:
>
> > I have a question about v22. We use
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 18 Nov 2024 17:02:41 -0800,
Masahiko Sawada wrote:
> I have a question about v22. We use pg_attribute_always_inline for
> some functions to avoid function call overheads
On Thu, Nov 14, 2024 at 4:04 PM Masahiko Sawada wrote:
>
> On Wed, Nov 13, 2024 at 11:19 PM Sutou Kouhei wrote:
> >
> > Hi,
> >
> > In <20241105.174328.1705956947135248653....@clear-code.com>
> > "Re: Make COPY format extendable: Extract COPY TO f
On Wed, Nov 13, 2024 at 11:19 PM Sutou Kouhei wrote:
>
> Hi,
>
> In <20241105.174328.1705956947135248653@clear-code.com>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 05 Nov 2024 17:43:28 +0900 (JST),
> Sut
On Thu, Oct 10, 2024 at 3:55 PM Masahiko Sawada wrote:
>
> On Tue, Oct 8, 2024 at 8:34 PM Michael Paquier wrote:
> >
> > On Mon, Oct 07, 2024 at 03:23:08PM -0700, Masahiko Sawada wrote:
> > > In the benchmark, I've applied the v20 patch set and 'master' in the
> > > result refers to a19f83f87966.
On Tue, Oct 8, 2024 at 8:34 PM Michael Paquier wrote:
>
> On Mon, Oct 07, 2024 at 03:23:08PM -0700, Masahiko Sawada wrote:
> > In the benchmark, I've applied the v20 patch set and 'master' in the
> > result refers to a19f83f87966. And I disabled CPU turbo boost where
> > possible. Overall, v20 pat
On Mon, Oct 07, 2024 at 03:23:08PM -0700, Masahiko Sawada wrote:
> In the benchmark, I've applied the v20 patch set and 'master' in the
> result refers to a19f83f87966. And I disabled CPU turbo boost where
> possible. Overall, v20 patch got a similar or better performance in
> both COPY FROM and CO
On Sat, Sep 28, 2024 at 8:56 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 27 Sep 2024 16:33:13 -0700,
> Masahiko Sawada wrote:
>
> >> * 0005 (that add "void *opa
Hi,
On Sun, Aug 4, 2024 at 3:20 PM Sutou Kouhei wrote:
>
> Hi,
>
> I re-ran the benchmark(*) with the v19 patch set and the
> following CPUs:
>
> 1. AMD Ryzen 9 3900X 12-Core Processor
> 2. Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
>
> (*)
> * Use tables that have {5,10,15,20,25,30} integer columns
On 7/30/24 09:13, Sutou Kouhei wrote:
> Hi,
>
> In <26541788-8853-4d93-86cd-5f701b13a...@enterprisedb.com>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 29 Jul 2024 14:17:08 +0200,
> Tomas Vondra wrote:
>
>&
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sun, 28 Jul 2024 22:49:47 +0800,
Junwang Zhao wrote:
> Thanks for updating the patches, I applied them and test
> in my local machine, I did not use tmpfs in my test, I guess
> if I r
Hi Sutou,
On Wed, Jul 24, 2024 at 4:31 PM Sutou Kouhei wrote:
>
> Hi,
>
> In <9172d4eb-6de0-4c6d-beab-8210b7a22...@enterprisedb.com>
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Mon, 22 Jul 2024 14:36:40 +0200,
> Toma
> On Jul 25, 2024, at 12:51, Sutou Kouhei wrote:
>
> Hi,
>
> THREAD SUMMARY:
Very nice summary.
>
> Implementation:
>
> The v18 patch set is the latest patch set. [6]
> It includes the following patches:
>
> 0001: This adds a basic feature (Copy{From,To}Routine)
> (This isn't enough
Hi,
THREAD SUMMARY:
Proposal:
How about making COPY format extendable?
Background:
Currently, COPY TO/FROM supports only "text", "csv" and
"binary" formats. There are some requests to support more
COPY formats. For example:
* 2023-11: JSON and JSON lines [1]
* 2022-04: Apache Arrow [2]
* 20
1 - 100 of 259 matches
Mail list logo
