at best sub-linearly (limited by the
velocity of knowledge sharing). I agree with Andrey on this, the only
way I see to handle this is to scale CF management efforts.
The number of items tracked are surely growing, but I am not sure I
would call it exponential -- see attached
--
Joe Conway
I'm
still here, please review my patch," we've already lost the game. That
person isn't sad because we asked them to click a link. They're sad
it's already been N * 2 months and nothing has happened.
+many
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon
On 5/17/24 09:08, Peter Eisentraut wrote:
On 17.05.24 14:42, Joe Conway wrote:
Namely, the week before commitfest I don't actually know if I will
have the time during that month, but I will make sure my patch is in
the commitfest just in case I get a few clear days to work on it.
Because
On 5/17/24 08:31, Jelte Fennema-Nio wrote:
On Fri, 17 May 2024 at 14:19, Joe Conway wrote:
On 5/16/24 22:26, Robert Haas wrote:
> For example, imagine that the CommitFest is FORCIBLY empty
> until a week before it starts. You can still register patches in the
> system generally, but
sing the point. What we really want is to not see that stuff in
the first place. It's a CommitFest, not
once-upon-a-time-I-wrote-a-patch-Fest.
+1
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 5/16/24 17:36, Jacob Champion wrote:
On Thu, May 16, 2024 at 2:29 PM Joe Conway wrote:
If no one, including the author (new or otherwise) is interested in
shepherding a particular patch, what chance does it have of ever getting
committed?
That's a very different thing from what I think
On 5/16/24 17:24, Jacob Champion wrote:
On Thu, May 16, 2024 at 2:06 PM Joe Conway wrote:
Maybe the word "care" was a poor choice, but forcing authors to think
about and decide if they have the "time to shepherd a patch" for the
*next CF* is exactly the point. If they don't
d "parking lot", where you can park patches
that aren't active in a commitfest but you also don't want to be dead.
It would probably also be doable to have the cf bot run patches in that
commitfest as well as the current one, if that's what people are using
it for there.
+1
--
J
On 5/16/24 16:57, Jacob Champion wrote:
On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
Maybe we should just make it a policy that *nothing* gets moved forward
from commitfest-to-commitfest and therefore the author needs to care
enough to register for the next one?
I think that's going
and therefore the author needs to care
enough to register for the next one?
I spent a good deal of time going through the CommitFest this week
And you deserve a big Thank You for that.
+ many
+1 agreed
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web
On 5/16/24 08:05, Joe Conway wrote:
On 5/15/24 21:45, Jonathan S. Katz wrote:
Please provide feedback no later than Wed 2024-05-22 18:00 UTC. As the
beta release takes some extra effort, I want to ensure all changes are
in with time to spare before release day.
"`EXPLAIN` can now sho
to note their work, while noting other, far
smaller, things in the release notes, pretty much tells us that our work isn't
valued.
agreed
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ation provider that provides
similar sorting semantics to the `C` collation except with UTF-8
encoding rather than SQL_ASCII."
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
s mostly is COPY of large rows and
streaming a base backup. That sounds user-visible enough to me to
warrant an entry imho.
+1
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
have better
connections.
Those docs were developed by the respective companies (Crunchy and EDB)
in cooperation with DISA. The community has nothing to do with them. I
suggest you contact the two companies with corrections and suggestions.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open
ce goes even further --
many such upgrade/migration uses, with exceedingly rare reported failures.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 4/26/24 09:31, Robert Haas wrote:
On Fri, Apr 26, 2024 at 9:22 AM Joe Conway wrote:
Although I don't think 50 is necessarily too small. In my view,
having autovac run very quickly, even if more frequently, provides an
overall better user experience.
Can you elaborate on why you think
,
having autovac run very quickly, even if more frequently, provides an
overall better user experience.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
need. It is extremely frustrating. But the solution is not to commit
anyway and then blame the other people for not providing feedback.
+many
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
certain certifications. Of course there is no guarantee that such
reviews would catch everything, but maybe we could establish post commit
reviews by contributors in a more rigorous way? Granted, getting more
qualified volunteers is not a trivial problem...
--
Joe Conway
PostgreSQL Contributors
that lesson
the hard way. I'm just distressed at our utter failure to learn
from experience.
I don't dispute that we could do better, and this is just a simplistic
look based on "number of commits per day", but the attached does put it
in perspective to some extent.
--
Joe Conway
On 3/31/24 11:49, Tom Lane wrote:
Joe Conway writes:
I am saying maybe those patches should be eliminated in favor of our
tree including build options that would produce the same result.
I don't really see how that can be expected to work sanely.
It turns the responsibility for platform
On 3/30/24 21:52, Bruce Momjian wrote:
On Sat, Mar 30, 2024 at 07:54:00PM -0400, Joe Conway wrote:
Virtually every RPM source, including ours, contains out of tree patches
that get applied on top of the release tarball. At least for the PGDG
packages, it would be nice to integrate them into our
On 3/30/24 19:54, Joe Conway wrote:
On 2024-03-30 16:50:26 -0400, Robert Haas wrote:
or what Tom does when he builds the release tarballs.
Tom follows this, at least last time I checked:
https://wiki.postgresql.org/wiki/Release_process
Reading through that, I wonder if this part is true
of assuming that bad things can't happen to
us.
+1
and again with the +1 ;-)
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ards would be gratefully accepted...
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
scribes the intended
use case.)
I agree with pretty much all of this.
+1 me too.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 3/9/24 15:39, Tom Lane wrote:
Joe Conway writes:
On 3/9/24 13:07, Tom Lane wrote:
BTW, while I didn't touch it here, it seems fairly bogus that
connectby() checks both type OID and typmod for its output
columns while crosstab() only checks type OID. I think
crosstab() is in the wrong
On 3/9/24 13:07, Tom Lane wrote:
Joe Conway writes:
On 3/5/24 17:04, Tom Lane wrote:
After reading the thread at [1], I could not escape the feeling
that contrib/tablefunc's error reporting is very confusing.
The changes all look good to me and indeed more consistent with the docs.
Do you
() checks both type OID and typmod for its output
columns while crosstab() only checks type OID. I think
crosstab() is in the wrong and needs to be checking typmod.
That might be fit material for a separate patch though.
I can take a look at this. Presumably this would not be for backpatching.
--
Joe
On 3/8/24 12:28, Andrey M. Borodin wrote:
Hello everyone!
Thanks for working on this, really nice feature!
On 9 Jan 2024, at 01:40, Joe Conway wrote:
Thanks -- will have a look
Joe, recently folks proposed a lot of patches in this thread that seem like
diverted from original way
typmod.
That might be fit material for a separate patch though.
Been a long time since I gave contrib/tablefunc any love I guess ;-)
I will have a look at your patches, and the other issue you mention, but
it might be a day or three before I can give it some quality time.
--
Joe Conway
of the PostgreSQL Contributors Team
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
the conversion even simpler.
That's a pretty convincing proof-of-concept. Let's just do this,
and then make sure to keep the file legible as plain text.
+1
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
.
+1
Markdown is pretty readable as text, I'm not sure why we need both.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 2/19/24 13:13, Andres Freund wrote:
On 2024-02-19 09:19:16 -0500, Joe Conway wrote:
Couldn't we scale the rounding, e.g. allow small allocations as we do now,
but above some number always round? E.g. maybe >= 2GB round to the nearest
256MB, >= 4GB round to the nearest 512MB, >=
do
now, but above some number always round? E.g. maybe >= 2GB round to the
nearest 256MB, >= 4GB round to the nearest 512MB, >= 8GB round to the
nearest 1GB, etc?
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
,
+ (errmsg("not available when using OpenSSL in FIPS
mode")));
Makes sense +1
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
reset
at org.postgresql.ssl.MakeSSL.convert(MakeSSL.java:43)
at
org.postgresql.core.v3.ConnectionFactoryImpl.enableSSL(ConnectionFactoryImpl.java:584)
at
org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:168)
/
/.../
Regards,
Madhu
--
J
sense to use
quote_literal_cstr() rather than defining your own appendEscapedValue()
function?
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
field name? (because if we keep
auth_method:identity it's not really the authname anyway).
I was worried system_user or sysuser would both be confusing with the
fact that we have usesysid -- which would reference a *different*
sys...
I think if it is exactly "system_user" it wo
On 1/8/24 14:36, Dean Rasheed wrote:
On Thu, 7 Dec 2023 at 01:10, Joe Conway wrote:
The attached should fix the CopyOut response to say one column.
Playing around with this, I found a couple of cases that generate an error:
COPY (SELECT 1 UNION ALL SELECT 2) TO stdout WITH (format json
On 1/6/24 15:10, Tom Lane wrote:
Joe Conway writes:
The only code specific comments were Tom's above, which have been
addressed. If there are no serious objections I plan to commit this
relatively soon.
I had not actually read this patchset before, but now I have, and
I have a few minor
On 1/6/24 13:16, Sehrope Sarkuni wrote:
On Sat, Jan 6, 2024 at 12:39 PM Joe Conway <mailto:m...@joeconway.com>> wrote:
The only code specific comments were Tom's above, which have been
addressed. If there are no serious objections I plan to commit this
relatively soon.
On 12/24/23 10:14, Joe Conway wrote:
On 12/23/23 11:00, Tom Lane wrote:
Joe Conway writes:
The attached patch set moves the guts of \password from psql into the
libpq client side -- PQchangePassword() (patch 0001).
Haven't really read the patch, just looked at the docs, but here's
a bit
to this discussion, because the new function
is called PQchangePassword().
The function PQencryptPasswordConn() has been around for a while and the
horse is out of the gate on that one.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
marking
the CF entry RwF for now.
It can always be reopened, if Joe or Tristan or Heikki or someone else
picks it up again.
It is definitely a bug, so I do plan to get back to it at some point,
hopefully sooner rather than later...
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source
that too, but see it as a separate feature. FWIW that is also
supported by the set_user extension referenced elsewhere on this thread.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
how long that is)
Such discussions are adapted in a commit fest entry. No idea if there
is a cooldown period after account creation before being able to touch
the CF app contents, though.
FWIW I have expedited the cooldown period, so Matthias can log in right
away.
--
Joe Conway
PostgreSQL
sion exits.
-----
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 12/27/23 16:09, Tom Lane wrote:
Joe Conway writes:
On 12/27/23 15:39, Peter Eisentraut wrote:
On 23.12.23 16:13, Joe Conway wrote:
The attached patch set moves the guts of \password from psql into the
libpq client side -- PQchangePassword() (patch 0001).
I don't follow how you get from
On 12/27/23 15:39, Peter Eisentraut wrote:
On 23.12.23 16:13, Joe Conway wrote:
I have recently, once again for the umpteenth time, been involved in
discussions around (paraphrasing) "why does Postgres leak the passwords
into the logs when they are changed". I know well that the
On 12/24/23 12:22, Tom Lane wrote:
Joe Conway writes:
Completely unrelated process bikeshedding:
I changed the naming scheme I used for the split patch-set this time. I
don't know if we have a settled/documented pattern for such naming, but
the original pattern which I borrowed from someone
On 12/23/23 11:00, Tom Lane wrote:
Joe Conway writes:
The attached patch set moves the guts of \password from psql into the
libpq client side -- PQchangePassword() (patch 0001).
Haven't really read the patch, just looked at the docs, but here's
a bit of bikeshedding:
Thanks!
* This seems
ion when setting a new password.
I will register this in the upcoming commitfest, but meantime
thought/comments/etc. would be gratefully received.
Thanks,
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.comdiff --git a/src/i
On 12/21/23 10:56, Melanie Plageman wrote:
On Sat, Dec 9, 2023 at 9:24 AM Joe Conway wrote:
However, even if we assume a more-or-less normal distribution, we should
consider using subgroups in a way similar to Statistical Process
Control[1]. The reasoning is explained in this quote
he shape of the population distribution. Therefore, as your
subgroup size increases, your control chart limits will narrow,
making the chart more sensitive to special cause variation and more
prone to false alarms.
[1]
https://www.qualitygurus.com/rational-subgrouping-in-statistical-process-con
On 12/8/23 14:45, Daniel Verite wrote:
Joe Conway wrote:
copyto_json.007.diff
When the source has json fields with non-significant line feeds, the COPY
output has these line feeds too, which makes the output incompatible
with rule #2 at https://jsonlines.org ("2. Each
ot;:1,"i":1}
,{"?column?":1,"i":2}
,{"?column?":1,"i":3}
]
8<--
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 12/7/23 08:52, Joe Conway wrote:
Or maybe this is preferred?
8<--
[{"ss":{"f1":1,"f2":1}},
{"ss":{"f1":1,"f2":2}},
{"ss":{"f1":1,"f2":3}}]
8<--
I don't know
On 12/7/23 08:35, Daniel Verite wrote:
Joe Conway wrote:
The attached should fix the CopyOut response to say one column. I.e. it
ought to look something like:
Spending more time with the doc I came to the opinion that in this bit
of the protocol, in CopyOutResponse (B)
...
Int16
test was over indexing on that one type. I am sure there
are other micro-optimizations to be made here, but I also think that it
is outside the scope of the COPY TO JSON patch.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 12/6/23 20:09, David G. Johnston wrote:
On Wed, Dec 6, 2023 at 5:57 PM Joe Conway <mailto:m...@joeconway.com>> wrote:
On 12/6/23 19:39, David G. Johnston wrote:
> On Wed, Dec 6, 2023 at 4:45 PM Joe Conway mailto:m...@joeconway.com>
> <mailto:m...@jo
On 12/6/23 18:09, Joe Conway wrote:
On 12/6/23 14:47, Joe Conway wrote:
On 12/6/23 13:59, Daniel Verite wrote:
Andrew Dunstan wrote:
IMNSHO, we should produce either a single JSON
document (the ARRAY case) or a series of JSON documents, one per row
(the LINES case).
"
On 12/6/23 19:39, David G. Johnston wrote:
On Wed, Dec 6, 2023 at 4:45 PM Joe Conway <mailto:m...@joeconway.com>> wrote:
" The backend sends a CopyOutResponse message to the frontend, followed
by zero or more CopyData messages (always one per row), followed by
On 12/6/23 18:38, David G. Johnston wrote:
On Wed, Dec 6, 2023 at 4:28 PM David G. Johnston
mailto:david.g.johns...@gmail.com>> wrote:
On Wed, Dec 6, 2023 at 4:09 PM Joe Conway mailto:m...@joeconway.com>> wrote:
On 12/6/23 14:47, Joe Conway wrote:
> O
On 12/6/23 18:28, David G. Johnston wrote:
On Wed, Dec 6, 2023 at 4:09 PM Joe Conway <mailto:m...@joeconway.com>> wrote:
On 12/6/23 14:47, Joe Conway wrote:
> On 12/6/23 13:59, Daniel Verite wrote:
>> Andrew Dunstan wrote:
>>
>>>
On 12/6/23 14:47, Joe Conway wrote:
On 12/6/23 13:59, Daniel Verite wrote:
Andrew Dunstan wrote:
IMNSHO, we should produce either a single JSON
document (the ARRAY case) or a series of JSON documents, one per row
(the LINES case).
"COPY Operations" in the doc says:
&qu
On 12/6/23 16:42, Sehrope Sarkuni wrote:
On Wed, Dec 6, 2023 at 4:29 PM Joe Conway <mailto:m...@joeconway.com>> wrote:
> 1. Outputting a top level JSON object without the additional column
> keys. IIUC, the top level keys are always the column names. A
common use
ow defaulting missing fields
to NULL.
good to record the ask, but applies to a different feature (COPY FROM
instead of COPY TO).
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
performance
left on the table to go after, no?
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ta correctly despite the extra CopyData messages.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 12/6/23 10:44, Tom Lane wrote:
Joe Conway writes:
I believe this is ready to commit unless there are further comments or
objections.
I thought we were still mostly at proof-of-concept stage?
The concept is narrowly scoped enough that I think we are homing in on
the final patch
On 12/6/23 10:32, Andrew Dunstan wrote:
On 2023-12-06 We 08:49, Joe Conway wrote:
On 12/6/23 07:36, Andrew Dunstan wrote:
On 2023-12-05 Tu 16:46, Joe Conway wrote:
On 12/5/23 16:20, Andrew Dunstan wrote:
On 2023-12-05 Tu 16:09, Joe Conway wrote:
On 12/5/23 16:02, Joe Conway wrote:
On 12
On 12/6/23 07:36, Andrew Dunstan wrote:
On 2023-12-05 Tu 16:46, Joe Conway wrote:
On 12/5/23 16:20, Andrew Dunstan wrote:
On 2023-12-05 Tu 16:09, Joe Conway wrote:
On 12/5/23 16:02, Joe Conway wrote:
On 12/5/23 15:55, Andrew Dunstan wrote:
and in any other case (e.g. LINES) I can't see why
On 12/5/23 16:20, Andrew Dunstan wrote:
On 2023-12-05 Tu 16:09, Joe Conway wrote:
On 12/5/23 16:02, Joe Conway wrote:
On 12/5/23 15:55, Andrew Dunstan wrote:
and in any other case (e.g. LINES) I can't see why you
would have them.
Oh I didn't address this -- I saw examples in the interwebs
On 12/5/23 16:12, Andrew Dunstan wrote:
On 2023-12-05 Tu 16:02, Joe Conway wrote:
On 12/5/23 15:55, Andrew Dunstan wrote:
On 2023-12-05 Tu 14:50, Davin Shearer wrote:
Hi Joe,
In reviewing the 005 patch, I think that when used with FORCE ARRAY,
we should also _imply_ FORCE ROW DELIMITER
On 12/5/23 16:02, Joe Conway wrote:
On 12/5/23 15:55, Andrew Dunstan wrote:
and in any other case (e.g. LINES) I can't see why you
would have them.
Oh I didn't address this -- I saw examples in the interwebs of MSSQL
server I think [1] which had the non-array with commas import and export
tting row delimiters false while
force_array is true here:
8<---
+ if (opts_out->force_array &&
+ force_row_delimiter_specified &&
+ !opts_out->force_row_delimiter)
+ ereport(ER
t;id":3,"f1":"aaa/bbb","f2":null}
{"id":4,"f1":"aaa\","f2":null}
{"id":5,"f1":"aaa\fbbb","f2":null}
{"id":6,"f1":"aaa\nbbb","f2":null}
{"id&q
On 12/4/23 21:54, Joe Conway wrote:
On 12/4/23 17:55, Davin Shearer wrote:
There are however a few characters that need to be escaped
1. |"|(double quote)
2. |\|(backslash)
3. |/|(forward slash)
4. |\b|(backspace)
5. |\f|(form feed)
6. |\n|(new line)
7. |\r|(carriage return)
8
rete plans to use this for anything, but I
thought it might be useful for extensions for caching, etc. and wanted to
see whether there was any interest in the feature.
Notwithstanding any dragons there may be, and not having actually looked
at the the patches, I love the concept! +
--
Joe Conway
t;,"filler":1}
{"style":"Unix","test":"abc\ndef","filler":2}
{"style":"Mac","test":"abc\rdef","filler":3}
{"style":"esc\\ape","test":"a\\r\\\r\\\n\\nb&quo
On 12/4/23 09:25, Andrew Dunstan wrote:
On 2023-12-04 Mo 08:37, Joe Conway wrote:
On 12/4/23 07:41, Andrew Dunstan wrote:
On 2023-12-03 Su 20:14, Joe Conway wrote:
(please don't top quote on the Postgres lists)
On 12/3/23 17:38, Davin Shearer wrote:
" being quoted as \\" break
On 12/4/23 07:41, Andrew Dunstan wrote:
On 2023-12-03 Su 20:14, Joe Conway wrote:
(please don't top quote on the Postgres lists)
On 12/3/23 17:38, Davin Shearer wrote:
" being quoted as \\" breaks the JSON. It needs to be \". This has
been my whole problem with COPY TO for
Davin -- how did you work around the issue with the way the built in
functions output JSON?
Andrew -- comments/thoughts?
Joe
On Sun, Dec 3, 2023, 10:51 Joe Conway <mailto:m...@joeconway.com>> wrote:
On 12/3/23 10:31, Davin Shearer wrote:
> Please be sure to include
On 12/3/23 14:52, Andrew Dunstan wrote:
On 2023-12-03 Su 14:24, Joe Conway wrote:
On 12/3/23 11:03, Joe Conway wrote:
On 12/3/23 10:10, Andrew Dunstan wrote:
I realize this is just a POC, but I'd prefer to see
composite_to_json()
not exposed. You could use the already public datum_to_json
On 12/3/23 11:03, Joe Conway wrote:
On 12/3/23 10:10, Andrew Dunstan wrote:
I realize this is just a POC, but I'd prefer to see composite_to_json()
not exposed. You could use the already public datum_to_json() instead,
passing JSONTYPE_COMPOSITE and F_RECORD_OUT as the second and third
On 12/3/23 11:03, Joe Conway wrote:
From your earlier post, regarding constructing the aggregate -- not
extensive testing but one data point:
8<--
test=# copy foo to '/tmp/buf' (format json, force_array);
COPY 1000
Time: 36353.153 ms (00:36.353)
test=# copy (sel
On 12/3/23 10:10, Andrew Dunstan wrote:
On 2023-12-01 Fr 14:28, Joe Conway wrote:
On 11/29/23 10:32, Davin Shearer wrote:
Thanks for the responses everyone.
I worked around the issue using the `psql -tc` method as Filip
described.
I think it would be great to support writing JSON using
"line with ' in it:
2456094","f2":"2023-12-03T10:44:40.971225-05:00"}
{"id":2456095,"f1":"line with \\" in it:
2456095","f2":"2023-12-03T10:44:40.971228-05:00"}
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On 12/2/23 17:37, Joe Conway wrote:
On 12/2/23 16:53, Nathan Bossart wrote:
On Sat, Dec 02, 2023 at 10:11:20AM -0500, Tom Lane wrote:
So if you are writing a production that might need to match
FORMAT followed by JSON, you need to match FORMAT_LA too.
Thanks for the pointer. That does seem
On 12/2/23 13:50, Maciek Sakrejda wrote:
On Fri, Dec 1, 2023 at 11:32 AM Joe Conway wrote:
1. Is supporting JSON array format sufficient, or does it need to
support some other options? How flexible does the support scheme need to be?
"JSON Lines" is a semi-standard format
);
}
+| FORMAT_LA copy_generic_opt_arg
+{
+$$ = makeDefElem("format", $2, @1);
+}
;
copy_generic_opt_arg:
Yep -- I concluded the same. Thanks Tom!
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
On 12/1/23 18:09, Nathan Bossart wrote:
On Fri, Dec 01, 2023 at 02:28:55PM -0500, Joe Conway wrote:
I did a quick PoC patch (attached) -- if there interest and no hard
objections I would like to get it up to speed for the January commitfest.
Cool. I would expect there to be interest, given
for processing,
and NiFi has superior handling of JSON (via JOLT parsers) versus CSV
where parsing is generally done with regex. I want to be able to emit
JSON using a postgres function and thus COPY TO.
Definitely +1 for COPY TO.
I don't think COPY FROM will work out well unless the JSON is requ
does it need to
support some other options? How flexible does the support scheme need to be?
2. This only supports COPY TO and we would undoubtedly want to support
COPY FROM for JSON as well, but is that required from the start?
Thanks for any feedback.
--
Joe Conway
PostgreSQL Contributors T
his does nothing to prevent OOM kills, which are becoming
more prevalent as, for example, running Postgres in a container (or
otherwise) with a cgroup memory limit becomes more popular.
And in any case, there are enterprise use cases that necessarily avoid
Postgres due to this behavior, which is
On 9/30/23 08:47, Joe Conway wrote:
The committfest app is down for repairs. We will reply back here once it
is back up.
The commitfest app is back up.
We restored to a backup from one day prior. We will take a look at what
changed in between, but it might be up to folks to redo some things
The committfest app is down for repairs. We will reply back here once it
is back up.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
1 - 100 of 412 matches
Mail list logo
