Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 9 May 2025 21:29:23 -0700,
Masahiko Sawada wrote:
>> > So the idea is that the backend process sets the format ID somewhere
>> > in st_progress_param, and then the progress view calls a SQL function,
>
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 9 May 2025 17:57:35 -0700,
Masahiko Sawada wrote:
>> Proposed approaches to register custom COPY formats:
>> a. Create a function that has the same name of custom COPY
>>format
>> b. Call a registe
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 May 2025 23:37:46 -0700,
Masahiko Sawada wrote:
> The progress information is stored in PgBackendStatus defined in
> backend_status.h:
>
> /*
> * Command progress reporting. Any command wh
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 3 May 2025 22:27:36 -0700,
"David G. Johnston" wrote:
> In any case, I’m doubtful either of us can make a convincing enough
> argument to sway the other fully. Both options are plausible, IMO. Others
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 May 2025 23:02:25 -0700,
Masahiko Sawada wrote:
> The progress view can know only numbers. We need to extend the
> progress view infrastructure so that we can pass other data types.
Sorry. Could you
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 May 2025 21:38:32 -0700,
Masahiko Sawada wrote:
>> How about requiring schema for all custom formats?
>>
>> Valid:
>>
>> COPY ... TO ... (FORMAT 'text');
>> COPY ... TO ... (FORMAT 'my_schema.jso
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 May 2025 15:52:49 -0700,
Masahiko Sawada wrote:
>> Hmm. How much should we care about the observability of the COPY
>> format used by a given backend? Storing this information in a
>> backend's Top
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 1 May 2025 12:15:30 -0700,
Masahiko Sawada wrote:
> One of the primary considerations we need to address is the treatment
> of the specified format name. The current patch set utilizes built-in
> forma
, I'll remove them.
>> >
>> > 3.: I don't have a strong opinion for it. If nobody objects
>> > it, I'll remove them.
>>
>> Is the 1. required for "ready for merge"? If so, is there
>> any suggestion? I don't have a strong opinion
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 copyfrom_internal.h and copyto.c,
> Shoul
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 tests
> included in th
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. But I don't see how that is prac
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 string literal" behavior. Having some of th
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 handler with namespace
>> * Wrong return t
).
> 4. Add CopyFromSkipErrorRow().
> 5. Documentation.
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 CO
sis. And redoing the two section opening paragraphs
> to better integrate with the content in the chapter opening.
>
> The rest I kinda went to town on...
Thanks!!! It's very helpful!!!
I've applied your patch. 0009 is only changed.
Thanks,
--
kou
>From a9aebf329a5388173b
English... 0009 in the attached v37 patch set
has a draft of it. It's based on existing documents in
doc/src/sgml/ and *.h.
0001-0007 aren't changed from v36 patch set.
Thanks,
--
kou
>From bd21411860e1ac8f751b77658bc7f1978a110d5f Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: M
> enum CopyDest. This is similar change for enum CopySource.
>
> 0006: This is COPY FROM version of 0003.
>
> 0007: This is for easy to implement "ON_ERROR stop" and
> "LOG_VERBOSITY verbose" in extension.
>
> We may want to squash 0005-0007 like for 000
or missing this in
our reviews...)!
How about the attached patch?
I'll rebase the v35 patch set after this is fixed.
Thanks,
--
kou
>From f21b48c7dd0b141c561e9c8a2c9f1d0e28aabfae Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Mon, 3 Mar 2025 09:13:37 +
cc5d1a54d0f6c7c47381533c879a9432fb925f Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Mon, 25 Nov 2024 12:19:15 +0900
Subject: [PATCH v35 1/7] Add support for adding custom COPY TO format
This uses the handler approach like tablesample. The approach creates
an internal function that retur
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://www.postgresql.org/message-id/CAD21AoBA414Q7
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
> alternative. For example
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() function:
>
> --- a/src/incl
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/copyfrom.c
> +++ b/src/backend/comm
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 attached the
> updated pat
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:
>
> +/* Implementation of the pe
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.
>>
>> In 0001, we have that:
>>
>> + /*
ode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("function %s must return type %s",
format, "copy_handler"),
parser_errposition(pstate, defel->location)));
Thanks,
--
kou
&g
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 function? It seems that
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 table and index methods
> h
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 use FORMAT option to add ne
n.
OK. I attach the v31 patch set that uses this
approach. Mainly, 0003 and 0006 were changed. The v31 patch
set also includes the above
copyapi.h/copy{to,from}_internal.h related changes.
If we have a feature that returns a function name from Oid,
we can improve error messages by including function
ceptable, let's
use the approach.
> Also, please check some regression test failures on cfbot.
Oh, sorry. I forgot to follow function name change in
0009. I attach the v30 patch set that fixes it in 0009.
Thanks,
--
kou
>From 4435e1d3bff645b84bb9fe1eb4da33e158ad2f9d Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date:
we can use static for
CopyToGetBuiltinRoutine()) but I applied your
suggestion. Because it's not a strong opinion.
> Copy[To|From]Routine for built-in formats are missing to set the node type.
Oh, sorry. I missed this.
Thanks,
--
kou
>From eef8c0bc18a489fea352db242dd9e16003132243 Mon Sep 1
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, 2
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 should be committed
> first
Hi,
In
"Re: confusing / inefficient "need_transcoding" handling in copy" on Mon, 16
Dec 2024 11:25:16 +0900,
Michael Paquier wrote:
> On Sat, Dec 14, 2024 at 04:46:57PM +0900, Michael Paquier wrote:
>> Note that using "test" as table name for the tests is not a good idea,
>> as this could
' AS skip_test \gset
> +\if :skip_test
> +\quit
>
> I guess that you have the file, forgot a `git add`.
I did "git add" but I attached a wrong file...
The v4 patch includes this too.
Thanks,
--
kou
>From 65976f2357da73ea0d821b3b071f479a1650169f Mon Sep 17 00:00:00 2
s. I didn't notice the portability problem. I've added
the skip trick.
> This requires an alternate output for the non-utf8 case.
Oh! I didn't know the "XXX_1.out" feature.
Thanks,
--
kou
>From 104c21bbd8d4fe063b74510d16be32372c4ac1bc Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Wed, 14 Feb 2024 1
Hi Michael,
ping.
(Do you think that this patch is still needed?)
Thanks,
--
kou
In <20240214.114608.2091541942684063981@clear-code.com>
"Re: confusing / inefficient "need_transcoding" handling in copy" on Wed, 14
Feb 2024 11:46:08 +0900 (JST),
Sutou Kou
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
>> > 3. Emitting JSON to file using COPY TO v13 patch set[1],
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 drawbacks, I test only COPY
atch set.
("format" -> "FORMAT" in COPY test changes are included.)
0009 exports the above code as
CopyFromSkipErrorRow(). Extensions should call it when they
use errsave() for a soft error in CopyFromOneRow callback.
Thanks,
--
kou
>From b95060713e5cfccc8b3db5acb34d352f18a8b1e2 Mon Sep 17 00:00:0
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 of CopyReadLine for text mode
>>
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 to be a better patch
> spl
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. Applying it to
> CopyToTextLik
Hi,
In <4ffb7317-7e92-4cbd-a542-1e478af6a...@manitou-mail.org>
"Re: Fixing backslash dot for COPY FROM...CSV" on Wed, 31 Jul 2024 15:42:41
+0200,
"Daniel Verite" wrote:
>> BTW, here is a diff after pgindent:
>
> PFA a v5 with the cosmetic changes applied.
Thanks for updating the patch.
>
Hi,
In <599e67d2-2929-4858-b8bc-f9c4ae889...@ebay.com>
"Re: Separate HEAP WAL replay logic into its own file" on Fri, 26 Jul 2024
07:56:12 +,
"Li, Yong" wrote:
>> 1. Could you create your patch by "git format-patch -vN master"
>> or something? If you create your patch by "git format-p
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 run the tests enough rou
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
rate_series(1, 500);
(*3) This SQL may be used for COPY TO:
COPY to_tab_30 TO '/dev/null' WITH (FORMAT text);
(*4) This SQL may be used for COPY FROM:
CREATE EXTENSION blackhole_am;
ALTER TABLE from_tab_30 SET ACCESS METHOD blackhole_am;
COPY to_tab_30 TO '/tmp/to_tab_30.txt&#x
Hi,
I'm reviewing patches in commitfest 2024-07:
https://commitfest.postgresql.org/48/
This is the 5th patch:
https://commitfest.postgresql.org/48/5054/
FYI: https://commitfest.postgresql.org/48/4681/ is my patch.
In
"Re: Separate HEAP WAL replay logic into its own file" on Tue, 18 Jun 2024
Hi Yong,
Thanks for joining this thread!
In <453d52d4-2ac5-49f6-928d-79f8a4c08...@ebay.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 22 Jul 2024 07:11:15 +,
"Li, Yong" wrote:
> My understanding is that the provided v17 patch aims to achieve the
Hi Tomas,
Thanks for joining this thread!
In <257d5573-07da-48c3-ac07-e047e7a65...@enterprisedb.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 19 Jul 2024 14:40:05 +0200,
Tomas Vondra wrote:
> I think it'd be helpful if you could post a patch status,
Hi,
I'm reviewing patches in Commitfest 2024-07 from top to bottom:
https://commitfest.postgresql.org/48/
This is the 4th patch:
https://commitfest.postgresql.org/48/4710/
FYI: https://commitfest.postgresql.org/48/4681/ is my patch.
In <2726138.1712462...@sss.pgh.pa.us>
"Re: Fixing backslash
Hi,
In
"July Commitfest: Entries Needing Review" on Thu, 18 Jul 2024 14:17:38 -0400,
Corey Huinker wrote:
> If you know your patch isn't going to get reviewed in this commitfest,
> please consider moving it to the next commitfest or withdrawing it.
I hope my patch https://commitfest.postgr
Hi,
I'm reviewing patches in Commitfest 2024-07 from top to bottom:
https://commitfest.postgresql.org/48/
This is the 3rd patch:
https://commitfest.postgresql.org/48/4583/
FYI: https://commitfest.postgresql.org/48/4681/ is my patch.
In
"Re: Wrong results with grouping sets" on Wed, 10 Jul 20
Hi,
I'm reviewing patches in Commitfest 2024-07 from top to bottom:
https://commitfest.postgresql.org/48/
This is the 2st patch:
https://commitfest.postgresql.org/48/4573/
FYI: https://commitfest.postgresql.org/48/4681/ is my patch.
In
"Re: pg_ctl start may return 0 even if the postmaster ha
Hi,
I'm reviewing patches in Commitfest 2024-07 from top to bottom:
https://commitfest.postgresql.org/48/
This is the 1st patch:
https://commitfest.postgresql.org/48/3874/
The latest patch can't be applied on master:
https://www.postgresql.org/message-id/CAFh8B=nnjtm9ke4_1mhpwgz2pv9yoyf6hmnyh5xa
Hi,
In
"Re: Columnar format export in Postgres" on Thu, 13 Jun 2024 22:30:24 +0530,
Sushrut Shivaswamy wrote:
> - To facilitate efficient querying it would help to export multiple
> parquet files for the table instead of a single file.
>Having multiple files allows queries to skip chun
Hi,
In
"Columnar format export in Postgres" on Wed, 12 Jun 2024 22:26:30 +0530,
Sushrut Shivaswamy wrote:
> I have been working on adding support for columnar format export to
> Postgres to speed up analytics queries.
FYI: I'm proposing making COPY format extendable:
*
https://www.postgr
Hi,
(I don't have an opinion which language should be selected
here.)
In
"Re: RFC: adding pytest as a supported test framework" on Wed, 12 Jun 2024
12:31:23 -0700,
Jacob Champion wrote:
> - I like Ruby as a language but have no experience using it for
> testing. (RSpec did come up during
Hi,
In <4707d4ed-f268-43c0-b4dd-cdbc7520f...@eisentraut.org>
"Re: meson: Specify -Wformat as a common warning flag for extensions" on Tue,
28 May 2024 23:31:05 -0700,
Peter Eisentraut wrote:
> On 07.04.24 18:01, Sutou Kouhei wrote:
>> +# We don't
Hi,
In <7a978dd2-371b-4d10-b58e-cb32ef728...@eisentraut.org>
"Re: Is it acceptable making COPY format extendable?" on Thu, 25 Apr 2024
09:59:18 +0200,
Peter Eisentraut wrote:
> PostgreSQL development is currently in feature freeze for PostgreSQL
> 17 (since April 8). So most participants w
Hi,
In
<779790c7-45d7-4010-9305-c3f9e6a60...@postgresql.org>,<779790c7-45d7-4010-9305-c3f9e6a60...@postgresql.org>
"2024-05-09 release announcement draft,2024-05-09 release announcement draft"
on Mon, 6 May 2024 13:44:05 -0400,
"Jonathan S. Katz" wrote:
> * Added optimization for certain o
Hi,
Thanks for replying this.
In <02cccd36-3083-4a50-aae4-f957e96fb...@eisentraut.org>
"Re: Is it acceptable making COPY format extendable?" on Wed, 24 Apr 2024
09:57:38 +0200,
Peter Eisentraut wrote:
>> I'm proposing a patch that making COPY format extendable:
>> https://www.postgresql.or
Hi,
I'm proposing a patch that making COPY format extendable:
https://www.postgresql.org/message-id/20231204.153548.2126325458835528809.kou%40clear-code.com
https://commitfest.postgresql.org/48/4681/
It's based on the discussion at:
https://www.postgresql.org/message-id/flat/3741749.1655952...@ss
Hi,
In <20240404143514.a26f7ttxrbdfc73a@erthalion.local>
"Re: pg_stat_statements and "IN" conditions" on Thu, 4 Apr 2024 16:35:14
+0200,
Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Here is the rebased version.
Thanks. I'm not familiar with this code base but I've
reviewed these patches b
-
kou
In <20240320.232732.488684985873786799@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 20 Mar 2024 23:27:32 +0900 (JST),
Sutou Kouhei wrote:
> Hi,
>
> Could someone review the v17 patch to proceed this?
>
> The v17 patch:
>
ood of warnings that way.
OK. I've removed "/W*" flags and warning_level==3/everything
cases.
How about the attached v5 patch?
Thanks,
--
kou
>From 205ef88c66cf1050eedfc1e72d951de93a02e53a Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Fri, 15 Mar 2024 18:27:30 +0900
Subject: [P
Hi,
In
"Re: Commitfest Manager for March" on Mon, 1 Apr 2024 11:57:27 +0300,
Heikki Linnakangas wrote:
> On 01/04/2024 09:05, Andrey M. Borodin wrote:
>> I think it makes sense to close this commitfest only after Feature
>> Freeze on April 8, 2024 at 0:00 AoE.
>> What do you think?
>
> +1.
%40paquier.xyz#eccfd1a0131af93c48026d691cc247f4
Thanks,
--
kou
In <20240308.092254.359611633589181574@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 08 Mar 2024 09:22:54 +0900 (JST),
Sutou Kouhei wrote:
> Hi,
>
&g
omeone who wants to write a fix for this, the relevant variable
> is var_cflags in our meson scripts. And var_cxxflags as well.
How about the attached v4 patch?
Thanks,
--
kou
>From a515720338dc49e764f598021200316c6d01ddf9 Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Fri, 15 Mar 202
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 13 Mar 2024 16:00:46 +0800,
jian he wrote:
>> More use cases will help us which callbacks are needed. We
>> will be able to collect more use cases by providing basic
>> callbacks.
> Let's say the cust
the wording! I used it for the v3 patch.
Thanks,
--
kou
>From 0ba2e6dd55b00ee8a57313a629a1e5fa8c9e40cc Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Wed, 13 Mar 2024 16:10:34 +0900
Subject: [PATCH v3] Add -Wformat to common warning flags
We specify -Wformat-security as a common warning f
Hi,
In
"Re: meson: Specify -Wformat as a common warning flag for extensions" on Fri,
08 Mar 2024 10:05:27 -0600,
"Tristan Partin" wrote:
> Ok, I figured this out. -Wall implies -Wformat=1. We set warning_level
> to 1 in the Meson project() call, which implies -Wall, and set -Wall
> in CFLA
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 11 Mar 2024 08:00:00 +0800,
jian he wrote:
> Hi, here are my cents:
> Currently in v17, we have 3 extra functions within DoCopyTo
> CopyToStart, one time, start, doing some preliminary work.
> CopyToOn
Hi,
In
"Re: meson: Specify -Wformat as a common warning flag for extensions" on Fri,
8 Mar 2024 15:32:22 +0900,
Michael Paquier wrote:
> Are there version and/or
> environment requirements to be aware of?
I'm using Debian GNU/Linux sid and I can
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 7 Mar 2024 15:32:01 +0900,
Michael Paquier wrote:
> While on it, here are some profiles based on HEAD and v17 with the
> previous tests (COPY TO /dev/null, COPY FROM data sent to the void).
>
...
>
>
mStateData::opaque
* Export CopyReadBinaryData()
[1]
https://www.postgresql.org/message-id/flat/20240124.144936.67229716500876806.kou%40clear-code.com#f1ad092fc5e81fe38d3c376559efd52c
Thanks,
--
kou
>From a78b8ee88575e2c2873afc3acf3c8c4e535becf0 Mon Sep 17 00:00:00 2001
From: Suto
Hi,
In <20240301.154443.618034282613922707@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 01 Mar 2024 15:44:43 +0900 (JST),
Sutou Kouhei wrote:
>> I guess so. It does not make much of a difference, though. Th
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 1 Mar 2024 14:31:38 +0900,
Michael Paquier wrote:
> I guess so. It does not make much of a difference, though. The thing
> is that the dispatch caused by the custom callbacks called for each
> row is
Hi,
In <20240222.183948.518018047578925034@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 22 Feb 2024 18:39:48 +0900 (JST),
Sutou Kouhei wrote:
> How about adding "is_csv" to CopyReadline() and
> CopyR
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 22 Feb 2024 15:44:16 +0900,
Michael Paquier wrote:
> I was comparing what you have here, and what's been attached by Andres
> at [1] and the top of the changes on my development branch at [2]
> (v3-000
as a common warning flag for extensions" on Mon, 22
Jan 2024 14:11:39 +0900 (JST),
Sutou Kouhei wrote:
> Hi,
>
> I'm an extension developer. If I use PostgreSQL built with
> Meson, I get the following warning:
>
> cc1: warning: '-Wformat-security'
Hi,
In <20240219195351.5vy7cdl3wxia6...@awork3.anarazel.de>
"Re: Why is pq_begintypsend so slow?" on Mon, 19 Feb 2024 11:53:51 -0800,
Andres Freund wrote:
>> I don't have a strong opinion how to implement this
>> optimization as I said above. It seems that you like your
>> approach. So I wit
Hi,
In <20240218200906.zvihkrs46yl2j...@awork3.anarazel.de>
"Re: Why is pq_begintypsend so slow?" on Sun, 18 Feb 2024 12:09:06 -0800,
Andres Freund wrote:
>> [1]
>> https://www.postgresql.org/message-id/flat/20240215.153421.96888103784986803.kou%40clear-code.com#34df359e6d255795d16814ce138c
Hi,
In <20240218015955.rmw5mcmobt5hb...@awork3.anarazel.de>
"Re: Why is pq_begintypsend so slow?" on Sat, 17 Feb 2024 17:59:55 -0800,
Andres Freund wrote:
> v3-0008-wip-make-in-out-send-recv-calls-in-copy.c-cheaper.patch
It seems that this is an alternative approach of [1].
[1]
https://ww
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 15 Feb 2024 17:09:20 +0800,
jian he wrote:
> My environment is slow (around 10x) but consistent.
> I see around 2-3 percent increase consistently.
> (with patch 7369.068 ms, without patch 7574.802 ms)
Hi,
In <20240213.173340.1518143507526518973@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 13 Feb 2024 17:33:40 +0900 (JST),
Sutou Kouhei wrote:
> I'll reply other comments later...
I've read other comment
7;t suitable for benchmark. So they may not
be valid numbers.
Thanks,
--
kou
>From b677732f46f735a5601b889f79671e91be41 Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Thu, 15 Feb 2024 15:01:08 +0900
Subject: [PATCH v2] Reuse fcinfo used in COPY FROM
Each NextCopyFrom() calls input fu
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 14 Feb 2024 12:28:38 +0900,
Michael Paquier wrote:
>> How about the attached patch approach? If it's a desired
>> approach, I can also write a separated patch for COPY TO.
>
> Hmm, I have not studied
ttached patch?
Thanks,
--
kou
>From 6eb9669f97c54f8b85fac63db40ad80664692d12 Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Wed, 14 Feb 2024 11:44:13 +0900
Subject: [PATCH v2] Add a test for invalid encoding for COPY FROM
The test data use an UTF-8 character (U+3042 HIRAGANA LETTER A) but
the test specifies
Hi,
In <20240209192705.5qdilvviq3py2...@awork3.anarazel.de>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 9 Feb 2024 11:27:05 -0800,
Andres Freund wrote:
>> +static void
>> +CopyFromTextInFunc(CopyFromState cstate, Oid atttypid,
>> +
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 9 Feb 2024 13:21:34 +0900,
Michael Paquier wrote:
>> - Revisit what we have here, looking at more profiles to see how HEAD
>> an v13 compare. It looks like we are on a good path, but let's tackle
>> t
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 7 Feb 2024 13:33:18 +0900,
Michael Paquier wrote:
> Hmm. That explains why I was not seeing any differences with this
> callback then. It seems to me that the order of actions to take is
> clear, lik
Hi,
In <20240208.172501.2177371292839763981@clear-code.com>
"Re: confusing / inefficient "need_transcoding" handling in copy" on Thu, 08
Feb 2024 17:25:01 +0900 (JST),
Sutou Kouhei wrote:
> How about the following to avoid needless transcoding?
Oh, sorry.
nt2,
generate_series(1, 100::int4)) TO '/dev/null' \watch c=5
Thanks,
--
kou
From 387f11bde4eb928af23f6a66101aa9d63b3dcfdf Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Thu, 8 Feb 2024 17:17:25 +0900
Subject: [PATCH v1] Add a test for invalid encoding for COPY FROM
The test data
Hi,
In <4b60e9bd-426c-4d4b-bbbd-1abd06fa0...@eisentraut.org>
"Re: meson: catalog/syscache_ids.h isn't installed" on Mon, 5 Feb 2024
17:53:52 +0100,
Peter Eisentraut wrote:
> On 05.02.24 02:29, Sutou Kouhei wrote:
>> catalog/syscache_ids.h is referred by ut
1 - 100 of 144 matches
Mail list logo
