Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 10 Jan 2024 16:53:48 +0900,
Masahiko Sawada wrote:
>> Interesting. But I feel that it introduces another (a bit)
>> tricky mechanism...
>
> Right. On the other hand, I don't think the idea 3 is good f
Hi,
Here is the current summary for a this discussion to make
COPY format extendable. It's for reaching consensus and
starting implementing the feature. (I'll start implementing
the feature once we reach consensus.) If you have any
opinion, please share it.
Confirmed:
1.1 Making COPY format exte
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 12 Jan 2024 14:40:41 +0800,
Junwang Zhao wrote:
>> Could you clarify what should we discuss? We should require
>> that COPY TO/FROM handlers should use PostgreSQL's memory
>> context for all internal m
gt; [10]
I'll export Copy{To,From}State.
Thanks,
--
kou
In <20240112.144615.157925223373344229@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 12 Jan 2024 14:46:15 +0900 (JST),
Sutou Kouhei wrote:
> Hi,
>
>
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 15 Jan 2024 16:03:41 +0900,
Masahiko Sawada wrote:
>> Defining one more static const struct instead of providing a
>> convenient (but a bit tricky) macro may be straightforward:
>>
>> static const Copy
clude -Wformat.
Can we specify -Wformat as a common warning flag too? If we
do it, "pg_config --cflags" includes both of
-Wformat-security and -Wformat. So I don't get the warning.
Thanks,
--
kou
>From 0913033512c9b75ee3d2941c89ff8696f3c5f53b Mon Sep 17 00:00:00 2001
From: S
ata(). CopyReadBinaryData() is renamed to
CopyFromStateRead().
Thanks,
--
kou
In <20240115.152702.2011620917962812379@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 15 Jan 2024 15:27:02 +0900 (JST),
Sutou Kouhei wrote:
&g
24, 2024 at 02:49:36PM +0900, Sutou Kouhei wrote:
>>> For COPY TO:
>>>
>>> 0001: This adds CopyToRoutine and use it for text/csv/binary
>>> formats. No implementation change. This just move codes.
>> 10M without this change:
>>
>> format,el
Hi,
In <20240124.144936.67229716500876806@clear-code.com>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 24 Jan 2024 14:49:36 +0900 (JST),
Sutou Kouhei wrote:
> I've implemented custom COPY format feature based on the
> cur
Hi,
Thanks for trying these patches!
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 25 Jan 2024 10:53:58 +0800,
jian he wrote:
> COPY data TO '/dev/null' WITH (FORMAT csv) \watch count=5
Wow! I didn't know the "\watch count="!
I'll use it.
> Time: 6
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 25 Jan 2024 12:17:55 +0900,
Michael Paquier wrote:
> +typedef bool (*CopyToProcessOption_function) (CopyToState cstate, DefElem
> *defel);
> +typedef int16 (*CopyToGetFormat_function) (CopyToState cst
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 25 Jan 2024 13:36:03 +0900,
Masahiko Sawada wrote:
> I've experimented with a similar optimization for csv
> and text format; have different callbacks for text and csv format and
> remo
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 26 Jan 2024 16:18:14 +0800,
Junwang Zhao wrote:
> In the current implementation, there is no way that one can check
> incompatibility
> options in ProcessCopyOptions, we can postpone the check in CopyF
n eliminate more "if (cstate->opts.csv_mode)" branches
such as one in NextCopyFromRawFields(). Should we do it
in this feature improvement (make COPY format
extendable)? Can we defer this as a separated improvement?
* Remove CopyFrom*_function typedefs
Thanks,
--
kou
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 26 Jan 2024 16:41:50 +0800,
Junwang Zhao wrote:
> CopyToProcessOption()/CopyFromProcessOption() can only handle
> single option, and store the options in the opaque field, but it can not
> check the r
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 27 Jan 2024 14:15:02 +0800,
Junwang Zhao wrote:
> I have been working on a *COPY TO JSON* extension since yesterday,
> which is based on your V6 patch set, I'd like to give you more input
> so you can
al() and pass the read
attributes callback explicitly to eliminate more
cstate->opts.csv_mode branches
Thanks,
--
kou
>From c136833f4a385574474b246a381014abeb631377 Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Fri, 26 Jan 2024 16:46:51 +0900
Subject: [PATCH v9 1/2] Extract COPY TO format implement
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 30 Jan 2024 11:11:59 +0900,
Masahiko Sawada wrote:
> ---
> +if (!format_specified)
> +/* Set the default format. */
> +ProcessCopyOptionFormatTo(pstate, opts_out
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 30 Jan 2024 16:20:54 +0900,
Michael Paquier wrote:
>>> +if (!format_specified)
>>> +/* Set the default format. */
>>> +ProcessCopyOptionFormatTo(pstate, opts_out
oState cstate, TupleTableSlot
*slot);
/* Called when COPY TO is ended. This will send a trailer. */
void(*CopyToEnd) (CopyToState cstate);
} CopyToRoutine;
Thanks,
--
kou
>From f827f1f1632dc330ef5d78141b85df8ca1bce63b Mon Sep 17 00:00:00 2
Hi,
Thanks for preparing benchmark.
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Thu, 1 Feb 2024 12:49:59 +0900,
Michael Paquier wrote:
> On Thu, Feb 01, 2024 at 10:57:58AM +0900, Michael Paquier wrote:
>> And here are the results I get for text and bina
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 Feb 2024 06:51:02 +0900,
Michael Paquier wrote:
> On Fri, Feb 02, 2024 at 12:19:51AM +0900, Sutou Kouhei wrote:
>> Here are some numbers on my local machine (Note that my
>
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 Feb 2024 15:21:31 +0900,
Michael Paquier wrote:
> I have done a review of v10, see v11 attached which is still WIP, with
> the patches for COPY TO and COPY FROM merged together. Note that I'm
> thin
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 Feb 2024 15:27:15 +0800,
Junwang Zhao wrote:
> I agree CopyToRoutine should be placed into CopyToStateData, but
> why set it after ProcessCopyOptions, the implementation of
> CopyToGetRoutine doesn't
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 2 Feb 2024 17:04:28 +0900,
Michael Paquier wrote:
> One idea I was considering is whether we should use a special value in
> the "format" DefElem, say "custom:$my_custom_format" where it would be
> pos
Hi,
catalog/syscache_ids.h is referred by utils/syscache.h but
it's not installed with Meson.
FYI:
* 9b1a6f50b91dca6610932650c8c81a3c924259f9
It uses catalog/syscache_ids.h in utils/syscache.h but
catalog/syscache_ids.h isn't installed.
* 6eb6086faa3842c2a38a1ee2f97bf9a42ce27610
It changes
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 5 Feb 2024 16:14:08 +0900,
Michael Paquier wrote:
> So, I've looked at all that today, and finished by applying two
> patches as of 2889fd23be56 and 95fb5b49024a to get some of the
> weirdness with the
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
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 <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.
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
"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, 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
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
%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
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.
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
-
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:
>
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,
>> +
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
"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
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 <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
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 <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 <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 <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
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
"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
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
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 <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
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
"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).
>
...
>
>
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
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,
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
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
151304.fonjztsynewldfba%40gmail.com
[4]:
https://www.postgresql.org/message-id/flat/3741749.1655952719%40sss.pgh.pa.us#2bb7af4a3d2c7669f9a49808d777a20d
[5]:
https://www.postgresql.org/message-id/20180211211235.5x3jywe5z3lkgcsr%40alap3.anarazel.de
[6]: https://www.postgresql.org/message-id/3741749.1655952719%40sss.pgh.pa.us
T
Hi,
Thanks for replying to this proposal!
In <20231205182458.GC2757816@nathanxps13>
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 5 Dec 2023 12:24:58 -0600,
Nathan Bossart wrote:
> I think it makes sense to do this part independently, but we should be
>
rly braces.
Thanks for the review! I attach the v2 patch that removes
extra curly braces for "if (isnull)".
Thanks,
--
kou
>From 2cd0d344d68667db71b621a8c94f376ddf1707c3 Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Mon, 4 Dec 2023 12:32:54 +0900
Subject: [PATCH v2] Extract CO
e, 0);
Thanks,
--
kou
>From 9fe0087d9a6a79a7d1a7d0af63eb16abadbf0d4a Mon Sep 17 00:00:00 2001
From: Sutou Kouhei
Date: Mon, 4 Dec 2023 12:32:54 +0900
Subject: [PATCH v3] Extract COPY TO format implementations
This is a part of making COPY format extendable. See also these past
discussions:
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 6 Dec 2023 22:07:51 +0800,
Junwang Zhao wrote:
> Should we extract both *copy to* and *copy from* for the first step, in that
> case we can add the pg_copy_handler catalog smoothly later.
I don't obje
Hi,
Thanks for reviewing our latest patch!
In
"RE: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 9 Dec 2023 02:43:49 +,
"Hayato Kuroda (Fujitsu)" wrote:
> (I remember that this theme was talked at Japan PostgreSQL conference)
Yes. I should have talke
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 8 Dec 2023 15:42:06 +0900,
Masahiko Sawada wrote:
> So a custom COPY extension would not be able to define SQL functions
> just like arrow(internal) for example. We might need to define a rule
> like t
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Sat, 9 Dec 2023 12:38:46 +0100,
Hannu Krosing wrote:
> Please also see my presentation slides from last years PostgreSQL
> Conference in Berlin (attached)
Thanks for sharing your idea here.
> The main Ide
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 11 Dec 2023 10:57:15 +0900,
Masahiko Sawada wrote:
> IIUC we cannot create two same name functions with the same arguments
> but a different return value type in the first place. It seems to me
> to be
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 15 Dec 2023 05:19:43 +0900,
Masahiko Sawada wrote:
> To avoid collisions, extensions can be created in a
> different schema than public.
Thanks. I didn't notice it.
> And note that built-in format co
Hi,
In
"RE: Make COPY format extendable: Extract COPY TO format implementations" on
Tue, 12 Dec 2023 02:31:53 +,
"Hayato Kuroda (Fujitsu)" wrote:
>> Can we discuss how to proceed this improvement?
>>
>> There are 2 approaches for it:
>>
>> 1. Do the followings concurrently:
>>
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 15 Dec 2023 11:27:30 +0800,
Junwang Zhao wrote:
>> > Adding a prefix or suffix would be one option but to give extensions
>> > more flexibility, another option would be to support format = 'custom'
>>
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Mon, 11 Dec 2023 23:31:29 +0900,
Masahiko Sawada wrote:
> I've sketched the above idea including a test module in
> src/test/module/test_copy_format, based on v2 patch. It's not splitted
> and is dirty so j
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 22 Dec 2023 10:00:24 +0900,
Michael Paquier wrote:
>> 3. Export CopySend*()
>>
>>* If we like minimum API, we just need to export
>> CopySendData() and CopySendEndOfRow(). But
>> CopySen
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 22 Dec 2023 10:48:18 +0900,
Masahiko Sawada wrote:
>> I needed to extend the patch:
>>
>> 1. Add an opaque space for custom COPY TO handler
>>* Add CopyToState{Get,Set}Opaque()
>>
>> https://gi
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 22 Dec 2023 10:58:05 +0800,
Junwang Zhao wrote:
>> 1. Add an opaque space for custom COPY TO handler
>>* Add CopyToState{Get,Set}Opaque()
>>
>> https://github.com/kou/postgres/commit/5a610b6a06
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Wed, 10 Jan 2024 15:33:22 +0900,
Masahiko Sawada wrote:
>> We can use the satic const struct approach by choosing one
>> of the followings:
>>
>> ...
>>
>> 4. ... other idea?
>
> It's a just idea but the f
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
"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,
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,
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,
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 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,
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
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,
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,
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,
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 <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
"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 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 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 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,
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
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,
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
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,
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 <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
"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, 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
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],
1 - 100 of 158 matches
Mail list logo
