Thanks Jelte and Robert for the extra effort to correct my mistake.
I apologize. Bad copy-paste from a previous revision of the patch at
some point.
--
Tristan Partin
Neon (https://neon.tech)
On Thu, Apr 4, 2024 at 6:43 AM Jelte Fennema-Nio wrote:
> But I don't agree with this. Having pg_unreachable in places where it
> brings no perf benefit has two main downsides:
>
> 1. It's extra lines of code
> 2. If a programmer/reviewer is not careful about maintaining this
> unreachable
On Wed, 3 Apr 2024 at 21:49, Robert Haas wrote:
> It seems to me that 0001 should either remove the pg_unreachable()
> call or change the break to a return, but not both.
Updated the patch to only remove the pg_unreachable call (and keep the breaks).
> but there's not much value in omitting
>
On Wed, Apr 3, 2024 at 11:17 AM Tristan Partin wrote:
> I think patch 2 makes it worse. The value in -Wswitch is that when new
> enum variants are added, the developer knows the locations to update.
> Adding a default case makes -Wswitch pointless.
>
> Patch 1 is still good. The comment change in
On Wed Apr 3, 2024 at 10:05 AM CDT, Jelte Fennema-Nio wrote:
On Wed, 3 Apr 2024 at 16:55, Tristan Partin wrote:
> Removing from the switch statement causes a warning:
>
> > [1/2] Compiling C object src/bin/psql/psql.p/command.c.o
> > ../src/bin/psql/command.c: In function
On Wed, 3 Apr 2024 at 16:55, Tristan Partin wrote:
> Removing from the switch statement causes a warning:
>
> > [1/2] Compiling C object src/bin/psql/psql.p/command.c.o
> > ../src/bin/psql/command.c: In function ‘wait_until_connected’:
> > ../src/bin/psql/command.c:3803:17: warning: enumeration
On Wed Apr 3, 2024 at 9:50 AM CDT, Jelte Fennema-Nio wrote:
On Wed, 3 Apr 2024 at 16:31, Tom Lane wrote:
> If we do the latter, we will almost certainly get pushback from
> distros who check for library ABI breaks. I fear the comment
> suggesting that we could remove it someday is too
On Wed, 3 Apr 2024 at 16:31, Tom Lane wrote:
> If we do the latter, we will almost certainly get pushback from
> distros who check for library ABI breaks. I fear the comment
> suggesting that we could remove it someday is too optimistic.
Alright, changed patch 0002 to keep the variant. But
Jelte Fennema-Nio writes:
> Looking at the committed version of this patch, the pg_unreachable
> calls seemed weird to me. 1 is actually incorrect, thus possibly
> resulting in undefined behaviour. And for the other call an imho
> better fix would be to remove the now 21 year unused enum variant,
On Wed Apr 3, 2024 at 8:32 AM CDT, Jelte Fennema-Nio wrote:
On Tue, 2 Apr 2024 at 16:33, Robert Haas wrote:
> Committed it, I did. My thanks for working on this issue, I extend.
Looking at the committed version of this patch, the pg_unreachable
calls seemed weird to me. 1 is actually
On Tue, 2 Apr 2024 at 16:33, Robert Haas wrote:
> Committed it, I did. My thanks for working on this issue, I extend.
Looking at the committed version of this patch, the pg_unreachable
calls seemed weird to me. 1 is actually incorrect, thus possibly
resulting in undefined behaviour. And for the
On Tue Apr 2, 2024 at 9:32 AM CDT, Robert Haas wrote:
On Mon, Apr 1, 2024 at 12:04 PM Tristan Partin wrote:
> > This sentence seems a bit contorted to me, like maybe Yoda wrote it.
>
> Incorporated feedback, I have :).
Committed it, I did. My thanks for working on this issue, I extend.
On Mon, Apr 1, 2024 at 12:04 PM Tristan Partin wrote:
> > This sentence seems a bit contorted to me, like maybe Yoda wrote it.
>
> Incorporated feedback, I have :).
Committed it, I did. My thanks for working on this issue, I extend.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon Mar 25, 2024 at 1:44 PM CDT, Robert Haas wrote:
On Fri, Mar 22, 2024 at 4:58 PM Tristan Partin wrote:
> I had a question about parameter naming. Right now I have a mix of
> camel-case and snake-case in the function signature since that is what
> I inherited. Should I change that to be
On Fri, Mar 22, 2024 at 4:58 PM Tristan Partin wrote:
> I had a question about parameter naming. Right now I have a mix of
> camel-case and snake-case in the function signature since that is what
> I inherited. Should I change that to be consistent? If so, which case
> would you like?
Uh...
On Fri Mar 22, 2024 at 12:17 PM CDT, Robert Haas wrote:
On Fri, Mar 22, 2024 at 1:05 PM Tristan Partin wrote:
> Sorry for taking a while to get back to y'all. I have taken your
> feedback into consideration for v9. This is my first time writing
> Postgres docs, so I'm ready for another round of
On Fri, Mar 22, 2024 at 1:05 PM Tristan Partin wrote:
> Sorry for taking a while to get back to y'all. I have taken your
> feedback into consideration for v9. This is my first time writing
> Postgres docs, so I'm ready for another round of editing :).
Yeah, that looks like it needs some
On Fri Mar 22, 2024 at 9:59 AM CDT, Robert Haas wrote:
On Wed, Jan 31, 2024 at 1:07 PM Tristan Partin wrote:
> I was looking for documentation of PQsocket(), but didn't find any
> standalone (unless I completely missed it). So I just copied how
> PQsocket() is documented in PQconnectPoll(). I
On Wed, Jan 31, 2024 at 1:07 PM Tristan Partin wrote:
> I was looking for documentation of PQsocket(), but didn't find any
> standalone (unless I completely missed it). So I just copied how
> PQsocket() is documented in PQconnectPoll(). I am happy to document it
> separately if you think it would
On Wed, 31 Jan 2024 at 19:07, Tristan Partin wrote:
> I was looking for documentation of PQsocket(), but didn't find any
> standalone (unless I completely missed it). So I just copied how
> PQsocket() is documented in PQconnectPoll(). I am happy to document it
> separately if you think it would
On Tue Jan 30, 2024 at 4:42 PM CST, Jelte Fennema-Nio wrote:
On Tue, 30 Jan 2024 at 23:20, Tristan Partin wrote:
> Not next week, but here is a respin. I've exposed pqSocketPoll as
> PQsocketPoll and am just using that. You can see the diff is so much
> smaller, which is great!
The exports.txt
On Tue, 30 Jan 2024 at 23:20, Tristan Partin wrote:
> Not next week, but here is a respin. I've exposed pqSocketPoll as
> PQsocketPoll and am just using that. You can see the diff is so much
> smaller, which is great!
The exports.txt change should be made part of patch 0001, also docs
are
On Fri Jan 12, 2024 at 11:13 AM CST, Tristan Partin wrote:
On Fri Jan 12, 2024 at 10:45 AM CST, Robert Haas wrote:
> On Mon, Jan 8, 2024 at 1:03 AM Tristan Partin wrote:
> > I think the way to go is to expose some variation of libpq's
> > pqSocketPoll(), which I would be happy to put together a
On Fri Jan 12, 2024 at 10:45 AM CST, Robert Haas wrote:
On Mon, Jan 8, 2024 at 1:03 AM Tristan Partin wrote:
> I think the way to go is to expose some variation of libpq's
> pqSocketPoll(), which I would be happy to put together a patch for.
> Making frontends, psql in this case, have to
On Mon, Jan 8, 2024 at 1:03 AM Tristan Partin wrote:
> I think the way to go is to expose some variation of libpq's
> pqSocketPoll(), which I would be happy to put together a patch for.
> Making frontends, psql in this case, have to reimplement the polling
> logic doesn't strike me as fruitful,
On Fri Jan 5, 2024 at 12:24 PM CST, Robert Haas wrote:
On Tue, Dec 5, 2023 at 1:35 PM Tristan Partin wrote:
> On Wed Nov 29, 2023 at 11:48 AM CST, Tristan Partin wrote:
> > I am not completely in love with the code I have written. Lots of
> > conditional compilation which makes it hard to read.
On Tue, Dec 5, 2023 at 1:35 PM Tristan Partin wrote:
> On Wed Nov 29, 2023 at 11:48 AM CST, Tristan Partin wrote:
> > I am not completely in love with the code I have written. Lots of
> > conditional compilation which makes it hard to read. Looking forward to
> > another round of review to see
On Wed Nov 29, 2023 at 11:48 AM CST, Tristan Partin wrote:
I am not completely in love with the code I have written. Lots of
conditional compilation which makes it hard to read. Looking forward to
another round of review to see what y'all think.
Ok. Here is a patch which just uses select(2)
On Thu Nov 23, 2023 at 3:19 AM CST, Heikki Linnakangas wrote:
On 22/11/2023 23:29, Tristan Partin wrote:
> Ha, you're right. I had this working yesterday, but convinced myself it
> didn't. I had a do while loop wrapping the blocking call. Here is a v4,
> which seems to pass the tests that were
On 22/11/2023 23:29, Tristan Partin wrote:
Ha, you're right. I had this working yesterday, but convinced myself it
didn't. I had a do while loop wrapping the blocking call. Here is a v4,
which seems to pass the tests that were pointed out to be failing
earlier.
Thanks! This suffers from a
On Wed Nov 22, 2023 at 3:00 PM CST, Heikki Linnakangas wrote:
On 22/11/2023 19:29, Tristan Partin wrote:
> On Thu Nov 16, 2023 at 8:33 AM CST, Heikki Linnakangas wrote:
>> On 06/11/2023 19:16, Tristan Partin wrote:
> That sounds like a much better solution. Attached you will find a v4
>
On 22/11/2023 19:29, Tristan Partin wrote:
On Thu Nov 16, 2023 at 8:33 AM CST, Heikki Linnakangas wrote:
On 06/11/2023 19:16, Tristan Partin wrote:
That sounds like a much better solution. Attached you will find a v4
that implements your suggestion. Please let me know if there is
something
On Thu Nov 16, 2023 at 8:33 AM CST, Heikki Linnakangas wrote:
On 06/11/2023 19:16, Tristan Partin wrote:
>>> That sounds like a much better solution. Attached you will find a v4
>>> that implements your suggestion. Please let me know if there is
>>> something that I missed. I can confirm that
On 06/11/2023 19:16, Tristan Partin wrote:
That sounds like a much better solution. Attached you will find a v4
that implements your suggestion. Please let me know if there is
something that I missed. I can confirm that the patch works.
This patch is missing a select(). It will busy loop until
On Thu Nov 2, 2023 at 4:03 AM CDT, Shlok Kyal wrote:
Hi,
> That sounds like a much better solution. Attached you will find a v4
> that implements your suggestion. Please let me know if there is
> something that I missed. I can confirm that the patch works.
>
> $
Hi,
> That sounds like a much better solution. Attached you will find a v4
> that implements your suggestion. Please let me know if there is
> something that I missed. I can confirm that the patch works.
>
> $ ./build/src/bin/psql/psql -h pg.neon.tech
> NOTICE: Welcome to Neon!
>
On Mon Jul 24, 2023 at 12:43 PM CDT, Tom Lane wrote:
"Tristan Partin" writes:
> v3 is attached which fixes up some code comments I added which I hadn't
> attached to the commit already, sigh.
I don't care for this patch at all. You're bypassing the pqsignal
abstraction layer that the rest
"Tristan Partin" writes:
> v3 is attached which fixes up some code comments I added which I hadn't
> attached to the commit already, sigh.
I don't care for this patch at all. You're bypassing the pqsignal
abstraction layer that the rest of psql goes through, and the behavior
you're
v3 is attached which fixes up some code comments I added which I hadn't
attached to the commit already, sigh.
--
Tristan Partin
Neon (https://neon.tech)
From 7f9554944911c77aa1a1900537a91e1e7bd75d93 Mon Sep 17 00:00:00 2001
From: Tristan Partin
Date: Mon, 24 Jul 2023 11:12:59 -0500
Subject:
v2 is attached which fixes a grammatical issue in a comment.
--
Tristan Partin
Neon (https://neon.tech)
From b9ccfc3c84a25b8616fd40495954bb6f77788e28 Mon Sep 17 00:00:00 2001
From: Tristan Partin
Date: Mon, 24 Jul 2023 11:12:59 -0500
Subject: [PATCH v2] Allow SIGINT to cancel psql database
On Mon Jul 24, 2023 at 12:00 PM CDT, Gurjeet Singh wrote:
On Mon, Jul 24, 2023 at 9:26 AM Tristan Partin wrote:
> attached patch
+/*
+ * Restore the default SIGINT behavior while within libpq.
Otherwise, we
+ * can never exit from polling for the database connection.
On Mon, Jul 24, 2023 at 9:26 AM Tristan Partin wrote:
> attached patch
+/*
+ * Restore the default SIGINT behavior while within libpq.
Otherwise, we
+ * can never exit from polling for the database connection. Failure to
+ * restore is non-fatal.
+ */
+
Neon provides a quick start mechanism for psql using the following
workflow:
$ psql -h pg.neon.tech
NOTICE: Welcome to Neon!
Authenticate by visiting:
https://console.neon.tech/psql_session/xxx
Upon navigating to the link, the user selects their database to
43 matches
Mail list logo
