On Mon, Aug 1, 2022 at 10:34 AM Alvaro Herrera wrote:
> On 2022-Aug-01, Tom Lane wrote:
> > Thanks for all your hard work on this! An active CFM really makes
> > things work better.
>
> Agreed, great work here.
Thanks, both of you!
> I hate to suggest even more work, but it would be excellent t
On 8/1/22 08:40, Jacob Champion wrote:
> I've just closed out the July commitfest. I'll be working to clear out
> all remaining active patches today.
"Today" was slightly optimistic. I'm down to the final stretch of forty
patches; I'll come back to those tomorrow with fresh eyes.
--Jacob
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
On Mon, Aug 1, 2022 at 10:38 AM Tom Lane wrote:
> > I can't see this on cfbot - either I don't know how to use it
> > properly, which is quite possible, or the results aren't showing up
> > because of the close of the July CommitFest.
>
> I think the latter --- the cfbot thinks the July CF is no l
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
https://commitfest.pos
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
On 6/30/22 16:16, Jacob Champion wrote:
> [CFM hat] Since you feel strongly about the patch, and we're short on
> time before the commitfest starts, I have re-registered this. That way
> there can be an explicit decision as opposed to a pocket veto by me.
[CFM hat] Okay, with anoth
[CFM hat] Okay, either way you look at it, this patchset needs author
work before any further review can be done. Peter has given some
additional feedback on next steps, Stephen has asked for clarification
on the goals of the patchset, etc. I feel pretty confident in marking
this Returned with Feed
On 6/22/22 06:31, Drouvot, Bertrand wrote:
> FWIW, I just created a new thread to expose the port->authn_id through
> the SYSTEM_USER sql reserved word.
Review for both seems to have dried up a bit. I'm not particularly
invested in my code, but I do want to see *a* solution go in. So if it
helps
>From looking at this patch and its history [1, 2], I think momentum was
probably lost during the January CF, where this patch was unregistered
(presumably by accident).
I've carried it forward, but it needs some help to keep from stalling
out. Definitely make sure it's rebased and up to date by t
On 8/2/22 15:09, Jacob Champion wrote:
> I've carried it forward, but it needs some help to keep from stalling
> out. Definitely make sure it's rebased and up to date by the time the
> next CF starts, to give it the best chance at getting additional review
> (if you haven&
On 8/1/22 16:08, Jacob Champion wrote:
> "Today" was slightly optimistic. I'm down to the final stretch of forty
> patches; I'll come back to those tomorrow with fresh eyes.
All right, every entry from July has been closed out or moved! Apologies
for dropping entries fr
On Tue, Aug 2, 2022 at 8:00 PM Julien Rouhaud wrote:
> I'm personally fine with the current statutes, as closing a patch with RwF
> explaining that there was no interest is still a feedback,
Hi Julien,
Making that explanation each time we intend to close a patch "needs
interest" takes a lot of t
On Wed, Aug 3, 2022 at 10:09 AM Julien Rouhaud wrote:
> First of all, I didn't want to imply that rejecting a patch should be
> pleasant,
> sorry if that sounded that way.
No worries, I don't think it really sounded that way. :D
> It's not that I'm opposed to adding that status, I just don't se
[was: CF app: add "Returned: Needs more interest"]
On Wed, Aug 3, 2022 at 10:09 AM Julien Rouhaud wrote:
> I'm afraid that
> patches will still be left alone to rot and there still be no clear rules on
> what to do and when, reminder for CFM and such, and that this new status would
> never be use
On 8/3/22 11:41, Andres Freund wrote:
> What patches are we concretely talking about?>
> My impression is that a lot of the patches floating from CF to CF have gotten
> sceptical feedback and at best a minor amount of work to address that has been
> done.
- https://commitfest.postgresql.org/38/248
Hi Andres,
My intention had not quite been for this to be a referendum on the
decision for every patch -- we can do that if it helps, but I don't
think we necessarily have to have unanimity on the bucketing for every
patch in order for the new state to be useful.
On 8/3/22 12:46, Andres Freund wr
On Wed, Aug 3, 2022 at 2:05 PM Matthias van de Meent
wrote:
> On Wed, 3 Aug 2022 at 20:04, Jacob Champion wrote:
> > Is that enough, or should we do more?
>
> "The CF Checklist" seems to refer to only the page that is (or seems
> to be) intended for the CFM only. We
On Thu, Aug 4, 2022 at 3:00 PM Andres Freund wrote:
> On 2022-08-04 11:19:28 -0700, Jacob Champion wrote:
> > My intention had not quite been for this to be a referendum on the
> > decision for every patch -- we can do that if it helps, but I don't
> > think we necessar
b
From a22ff3ba36f5eb93c582a957c7c2caca07ed21c5 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Wed, 23 Mar 2022 15:07:05 -0700
Subject: [PATCH] Allow parallel workers to read authn_id
Move authn_id into a new global, MyClientConnectionInfo, which is
intended to hold all the client information that needs to be shared
b
to copy the auth_method over as well. It
"passes tests" but is otherwise unexercised.
Thanks,
--Jacob
commit 69cacd5e0869b18d64ff4233ef6a73123c513496
Author: Jacob Champion
Date: Thu Aug 11 15:16:15 2022 -0700
squash! Allow parallel workers to read authn_id
Add a copy o
On Wed, 2021-08-25 at 16:15 -0400, John Naylor wrote:
> On Tue, Aug 24, 2021 at 1:50 PM Jacob Champion wrote:
> >
> > Does there need to be any sanity check for overlapping ranges between
> > the combining and fullwidth sets? The Unicode data on a dev's machine
> >
On Wed, 2021-08-25 at 15:25 -0700, Zhihong Yu wrote:
>
> Hi,
> For v2-0001-common-jsonapi-support-FRONTEND-clients.patch :
>
> + /* Clean up. */
> + termJsonLexContext(&lex);
>
> At the end of termJsonLexContext(), empty is copied to lex. For stack
> based JsonLexContext, the copy seems unn
jor support hazard. The
TODO is still in the code to remind me to have the conversation.
WDYT?
--Jacob
[1]
https://www.postgresql.org/message-id/94f6b945f9ca8cabe2b9d2a38ec19dca6f90a083.camel%40vmware.com
From 24d58279bb85340a55ed618a60a20b0483ac3a0a Mon Sep 17 00:00:00 2001
From: Jacob Champion
On Fri, 2021-08-27 at 11:32 +0900, Michael Paquier wrote:
> Now if you'd really wish to
> stress that without relying on the backend, one simple way is to use
> pgbench -C -n with a mostly-empty script (one meta-command) coupled
> with some profiling.
Ah, thanks! I'll add that to the toolbox.
--J
On Tue, 2021-08-31 at 19:39 +, Jacob Champion wrote:
> Hello,
>
> There was a brief discussion [1] back in February on allowing user
> mapping for LDAP, in order to open up some more complex authorization
> logic (and slightly reduce the need for LDAP-to-Postgres user
&g
On Fri, 2021-08-27 at 15:02 +0900, Michael Paquier wrote:
> On Fri, Aug 13, 2021 at 12:08:16AM +0000, Jacob Champion wrote:
> > (Things would get hairier if someone included the SSL Makefile
> > somewhere else, but I don't see anyone doing that now and I don't k
On Wed, 2021-09-01 at 15:42 +, Jacob Champion wrote:
> The cfbot found a failure in postgres_fdw, which I completely neglected
> in my design. I think the desired functionality should be to allow the
> ldapuser connection option during CREATE USER MAPPING but not CREATE
> SERVER.
On Wed, 2021-09-01 at 12:59 -0700, Zhihong Yu wrote:
> + if (strcmp(val, "1") == 0)
> + hbaline->ldap_map_dn = true;
> + else
> + hbaline->ldap_map_dn = false;
>
> The above can be shortened as:
>
> hbaline->ldap_map_dn = strcmp(val, "1") == 0;
I usually prefer
On Wed, 2021-09-01 at 14:20 -0700, Zhihong Yu wrote:
> I looked at v2-Allow-user-name-mapping-with-LDAP.patch
> and src/backend/postmaster/postmaster.c in master branch but didn't
> find what you mentioned.
This hunk is in src/backend/libpq/hba.c, in the parse_hba_auth_opt()
function. The code the
On Fri, 2021-08-27 at 15:02 +0900, Michael Paquier wrote:
> On Fri, Aug 13, 2021 at 12:08:16AM +0000, Jacob Champion wrote:
> > If _that's_ the case, then our build system is holding all of us
> > hostage. Which is frustrating to me. Should I shift focus to help with
> &g
On Fri, 2021-07-23 at 05:34 +, tanghy.f...@fujitsu.com wrote:
> On Thursday, July 22, 2021 1:05 PM, tanghy.f...@fujitsu.com
> wrote
> > I found a problem when using tab-completion as follows:
> >
> > CREATE SUBSCRIPTION my_subscription
> > CONNECTION 'host=localhost port=5432 dbname=postgre
On Tue, 2021-08-17 at 16:36 +0200, Peter Eisentraut wrote:
> Here is another set of preparatory patches that clean up various special
> cases and similar in the node support.
>
> 0001-Remove-T_Expr.patch
>
> Removes unneeded T_Expr.
>
> 0002-Add-COPY_ARRAY_FIELD-and-COMPARE_ARRAY_FIELD.patch
>
On Fri, 2021-09-03 at 09:46 +0900, Michael Paquier wrote:
> Nice. This is neat. The split helps a lot to understand how you've
> changed things from the original implementation. As a whole, this
> looks rather committable to me.
Great!
> One small-ish comment that I have is about all the .conf
Hi Tang,
On Fri, 2021-09-03 at 04:32 +, tanghy.f...@fujitsu.com wrote:
> I'd appreciate it if you can share your test results with me.
Sure! Here's my output (after a `make clean && make`):
cd . && TESTDIR='/home/pchampion/workspace/postgres/src/bin/psql'
PATH="/home/pchampion/workspace
On Sat, 2021-09-04 at 11:32 -0400, Tom Lane wrote:
> Jacob Champion writes:
> > t/010_tab_completion.pl .. 17/?
> > # Failed test 'tab-completion after single quoted text input with
> > equal sign'
> > # at t/010_tab_completion.pl line 198
On Tue, 2021-09-07 at 12:24 +0200, Magnus Hagander wrote:
> On Wed, Jul 14, 2021 at 8:24 PM Jacob Champion wrote:
> > On Mon, 2021-07-12 at 18:28 +0200, Magnus Hagander wrote:
> > > Yeah, I have no problem being stricter than necessary, unless that
> > > actually causes
On Wed, 2021-09-08 at 17:08 -0400, Tom Lane wrote:
> Jacob Champion writes:
> > On Sat, 2021-09-04 at 11:32 -0400, Tom Lane wrote:
> > > Independently of the concerns I raised, I'm wondering how come you
> > > are getting different results. Which readline or lib
On Wed, 2021-09-08 at 18:51 +, Jacob Champion wrote:
> I still owe you that overall review. Hoping to get to it this week.
And here it is. I focused on things other than UnwrapProxyConnection()
for this round, since I think that piece is looking solid.
> + if (port-&g
On Fri, 2021-09-10 at 23:48 +0800, Julien Rouhaud wrote:
> I totally agree that batching as many file as possible in a single
> command is probably what's gonna achieve the best performance. But if
> the archiver only gets an answer from the archive_command once it
> tried to process all of the fi
On Mon, 2021-09-13 at 15:04 +0200, Daniel Gustafsson wrote:
> A few things noted (and fixed as per the attached, which is v6 squashed and
> rebased on HEAD; commitmessage hasn't been addressed yet) while reviewing:
>
> * Various comment reflowing to fit within 79 characters
>
> * Pass through the
On Mon, 2021-07-26 at 15:26 +0200, Daniel Gustafsson wrote:
> > On 19 Jul 2021, at 21:33, Jacob Champion wrote:
> > ..client connections will crash if
> > hostaddr is provided rather than host, because SSL_SetURL can't handle
> > a NULL argument. I'm running
On Wed, 2021-09-22 at 10:20 +0200, Peter Eisentraut wrote:
> This should be added to each level of a function call that represents a
> test. This ensures that when a test fails, the line number points to
> the top-level location of the test_role() call. Otherwise it would
> point to the connec
On Sat, 2021-09-18 at 14:20 +0200, Cameron Murdoch wrote:
> Having sslrootcert use the system trust store if
> ~/.postgresql/root.crt doesn’t exist would seem like a good change.
Fallback behavior can almost always be exploited given the right
circumstances. IMO, if I've told psql to use a root ce
On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
> > On 21 Sep 2021, at 02:06, Jacob Champion wrote:
> > but I'm not sure that would be
> > correct either. If the user has the default sslsni="1" and supplies an
> > IP address for the host para
On Tue, 2021-09-28 at 15:38 +0200, Magnus Hagander wrote:
> I'm a bit hesitant about the ldapuser libpq parameter. Do we really
> want to limit ourselves to just ldap, if we allow this? I mean, why
> not allow say radius or pam to also specify a different username for
> the external system? If we w
On Tue, 2021-09-28 at 18:02 +, Jacob Champion wrote:
> On Tue, 2021-09-28 at 15:38 +0200, Magnus Hagander wrote:
> > I'm a bit hesitant about the ldapuser libpq parameter. Do we really
> > want to limit ourselves to just ldap, if we allow this? I mean, why
> > not
On Tue, 2021-09-28 at 18:08 +, Jacob Champion wrote:
> > | authn authz
> > -+---
> > envvar | PGAUTHUSERPGUSER
> > conninfo | authuser user
> > frontend | conn->pgauthuser conn-
On Thu, 2021-09-30 at 14:17 +0200, Daniel Gustafsson wrote:
> The libpq libnss implementation doesn't call either of these, and neither does
> libnss.
I thought the refs check only searched for direct symbol dependencies;
is that piece of NSPR being statically included somehow?
> I'm not entirely
On Thu, 2021-09-30 at 16:04 +, Jacob Champion wrote:
> On Thu, 2021-09-30 at 14:17 +0200, Daniel Gustafsson wrote:
> > The libpq libnss implementation doesn't call either of these, and neither
> > does
> > libnss.
>
> I thought the refs check only searche
On Mon, 2021-10-04 at 23:40 +0700, Anton Voloshin wrote:
>
> Could you please confirm that the change from -A to -a in nm arguments
> in this patch is intentional?
That was not intended by us, thank you for the catch! A stray
lowercasing in vim, perhaps.
--Jacob
On Tue, 2021-10-05 at 15:08 +0200, Daniel Gustafsson wrote:
> Thanks! These changes looks good. Since you accidentally based this on v43
> and not the v44 I posted with the cryptohash fix in, the attached is a v45
> with
> both your v44 and the previous one, all rebased over HEAD.
Thanks, and s
On Tue, 2021-07-13 at 19:31 +0900, Michael Paquier wrote:
> On Tue, Jul 13, 2021 at 12:41:27PM +0300, Mikhail Kulagin wrote:
> > I got an error while building one of the extensions.
> > /home/mkulagin/pg-install/postgresql-master/include/internal/libpq-int.h:44:10:
> > fatal error: fe-auth-sasl.h:
On Tue, 2021-07-13 at 22:41 +, Jacob Champion wrote:
> On Tue, 2021-07-13 at 19:31 +0900, Michael Paquier wrote:
> > On Tue, Jul 13, 2021 at 12:41:27PM +0300, Mikhail Kulagin wrote:
> > >
> > > I think the new fe-auth-sasl.h file should be installed too.
>
On Mon, 2021-07-12 at 18:28 +0200, Magnus Hagander wrote:
> Yeah, I have no problem being stricter than necessary, unless that
> actually causes any interop problems. It's a lot worse to not be
> strict enough..
Agreed. Haven't heard back from the HAProxy mailing list yet, so
staying strict seems
On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote:
> On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote:
> > v4-0001 mostly teaches test.sh about specific changes that have to be
> > made to historic versions of the regression database to allow them
> > to be reloaded into current server
On Fri, 2021-07-16 at 16:21 +, Jacob Champion wrote:
> On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote:
> > On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote:
> > > v4-0001 mostly teaches test.sh about specific changes that have to be
> > > made
On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote:
> On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote:
> > v4-0001 mostly teaches test.sh about specific changes that have to be
> > made to historic versions of the regression database to allow them
> > to be reloaded into current server
age is included in later
unrelated failures. 0004 patches that.
--Jacob
From a675f4b6808c695d3691ad8a1a5e004ed71312c3 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Tue, 15 Jun 2021 15:59:39 -0700
Subject: [PATCH 1/4] nss: move SSL_ClearSessionCache
Don't clear the cache if no context exists.
On Mon, 2021-07-19 at 13:13 +0200, Laurenz Albe wrote:
> On Mon, 2021-07-19 at 16:46 +0900, Michael Paquier wrote:
> > > In your opinion, would the current one-line patch proposal make things
> > > strictly better than they are today, or would it have mixed results?
> > > I'm wondering how to help
On Wed, 2021-07-21 at 00:08 +, Jacob Champion wrote:
> On Mon, 2021-07-19 at 13:13 +0200, Laurenz Albe wrote:
> > That could be adapted; the question is if the approach as such is
> > desirable or not. This is necessarily a moving target, at the rate
> > that emojis are
On Wed, 2021-07-21 at 00:08 +, Jacob Champion wrote:
> I note that the doc comment for ucs_wcwidth()...
>
> > *- Spacing characters in the East Asian Wide (W) or East Asian
> > * FullWidth (F) category as defined in Unicode Technical
> > *
On Fri, 2021-07-23 at 17:42 +0200, Pavel Stehule wrote:
> čt 22. 7. 2021 v 0:12 odesílatel Jacob Champion napsal:
> >
> > Pavel, I'd be interested to see what your benchmarks find with this
> > code. Does this fix the original issue for you?
>
> I can confirm
On Wed, 2021-07-28 at 00:24 +0200, Daniel Gustafsson wrote:
> > On 4 Mar 2021, at 01:03, Jacob Champion wrote:
> > Andrew pointed out elsewhere [1] that it's pretty difficult to add new
> > certificates to the test/ssl suite without blowing away the current
> > stat
On Thu, 2021-08-12 at 12:36 -0400, John Naylor wrote:
> I tried this patch on and MacOS11/iterm2 and RHEL 7 (ssh'd from the Mac, in
> case that matters) and the example shown at the top of the thread shows no
> difference:
>
> john.naylor=# \pset border 2
> Border style is 2.
> john.naylor=# SEL
On Thu, 2021-08-12 at 17:13 -0400, John Naylor wrote:
> The patch looks pretty good to me. I just have a stylistic suggestion
> which I've attached as a text file.
Getting rid of the "clever addition" looks much better to me, thanks. I
haven't verified the changes to the doc comment, but your desc
On Tue, 2021-08-10 at 16:22 +0900, Michael Paquier wrote:
> Regarding 0002, I am not sure. Even if this reduces a lot of
> duplication, which is really nice, enforcing .SECONDARY to not trigger
> with a change impacting Makefile.global.in does not sound very
> appealing to me in the long-run, TBH.
On Tue, 2021-08-10 at 11:26 -0400, Tom Lane wrote:
> Yeah, I don't like that change either. It would be one thing if
> we had several places in which suppressing .SECONDARY was useful,
> but if there's only one then it seems better to design around it.
Maybe. The current Makefile already tried to
On Mon, 2021-08-16 at 11:24 -0400, John Naylor wrote:
>
> On Sun, Aug 15, 2021 at 10:45 PM Michael Paquier wrote:
>
> > How large do libpgcommon deliverables get with this patch? Skimming
> > through the patch, that just looks like a couple of bytes, still.
>
> More like a couple thousand byte
On Tue, 2021-08-10 at 19:22 +0200, Daniel Gustafsson wrote:
> Another rebase to work around the recent changes in the ssl Makefile.
I have a local test suite that I've been writing against libpq. With
the new ssldatabase connection option, one tricky aspect is figuring
out whether it's supported o
On Thu, 2021-08-19 at 13:49 -0400, John Naylor wrote:
> I had a couple further thoughts:
>
> 1. The coding historically used normal comparison and branching for
> everything, but recently it only does that to detect control
> characters, and then goes through a binary search (and with this
> patch
On Fri, 2021-08-20 at 13:05 -0400, John Naylor wrote:
> On Thu, Aug 19, 2021 at 8:05 PM Jacob Champion wrote:
> > I guess it just depends on what the end result looks/performs like.
> > We'd save seven hops or so in the worst case?
>
> Something like that. Attached is
On Fri, Jun 7, 2024 at 3:02 AM Erica Zhang wrote:
>
> For some security consideration, we prefer to use TLS1.3 cipher suites in our
> product with some customization values instead of default value
> "HIGH:MEDIUM:+3DES:!aNULL". Moreover we prefer to set a group of ecdh keys
> instead of a singl
Hi all,
For the v18 cycle, I would like to try to get pytest [1] in as a
supported test driver, in addition to the current offerings.
(I'm tempted to end the email there.)
We had an unconference session at PGConf.dev [2] around this topic.
There seemed to be a number of nodding heads and some gr
r implementations.
- I don't personally care for Perl, but having tests in any form is
usually better than not having them.
- Trying to convince people to get rid of X while adding Y is a good
way to make sure Y never happens.
> On 2024-06-10 11:46:00 -0700, Jacob Champion wrote:
> > 4.
On Mon, Jun 10, 2024 at 12:26 PM Alexander Korotkov
wrote:
> Thank you for working on this.
> Do you think you could re-use something from testgres[1] package?
Possibly? I think we're all coming at this with our own bags of tricks
and will need to carve off pieces to port, contribute, or reimplem
On Tue, Jun 11, 2024 at 4:48 PM Noah Misch wrote:
> If we're going to test in a non-Perl language, I'd pick C over Python.
We already test in C, though? If the complaint is that those tests are
driven by Perl, I agree that something like libcheck or GTest or
whatever people are using nowadays wou
On Wed, Jun 12, 2024 at 4:40 AM Jelte Fennema-Nio wrote:
> I think C#, Java, Go, Rust, Kotlin, and Swift would be acceptable
> choices for me (and possibly some more). They allow some type of
> introspection, they have a garbage collector, and their general
> tooling is quite good.
>
> But I think
On Wed, Jun 12, 2024 at 4:48 AM Alexander Korotkov wrote:
> Generally, testgres was initially designed as Python analogue of what
> we have in src/test/perl/PostgreSQL/Test. In particular its
> testgres.PostgresNode is analogue of PostgreSQL::Test::Cluster. It
> comes under PostgreSQL License.
On Wed, Jun 12, 2024 at 8:50 AM Andres Freund wrote:
> I think I might have formulated my paragraph above badly - I didn't mean that
> we should move away from perl tests tomorrow, but that we need a path forward
> that allows folks to write tests without perl.
Okay, agreed.
> > - Tests aren't c
On Wed, Jun 12, 2024 at 10:30 AM Daniel Gustafsson wrote:
> I might be missing something obvious, but if we use a third-party libpq driver
> in the testsuite doesn't that imply that a patch adding net new functionality
> to libpq also need to add it to the driver in order to write the tests?
I us
601 - 700 of 1187 matches
Mail list logo
