On Mon, Jun 23, 2025 at 09:44:29AM +0200, Jelte Fennema-Nio wrote:
> On Mon, 23 Jun 2025 at 09:40, Michael Paquier wrote:
>> This renaming patch looks correct to me. I am not seeing any missing
>> references of \close remaining, including APIs, comments and docs.
>
> Agreed
Applied.
--
Michael
On 23.06.25 09:04, Anthonin Bonnefoy wrote:
On Thu, Jun 19, 2025 at 9:09 AM Michael Paquier wrote:
Good point. I would be on board with a \close_prepared then, if
that's the consensus we reach, without touching at \bind_named. We
still have time to decide on the name until the release, just l
On Mon, Jun 23, 2025 at 09:04:15AM +0200, Anthonin Bonnefoy wrote:
> Since the consensus seems to lean toward \close_prepared, I've
> prepared the patch to rename the command.
This renaming patch looks correct to me. I am not seeing any missing
references of \close remaining, including APIs, comm
On Mon, 23 Jun 2025 at 09:40, Michael Paquier wrote:
>
> On Mon, Jun 23, 2025 at 09:04:15AM +0200, Anthonin Bonnefoy wrote:
> > Since the consensus seems to lean toward \close_prepared, I've
> > prepared the patch to rename the command.
>
> This renaming patch looks correct to me. I am not seeing
On Thu, 19 Jun 2025 at 09:09, Michael Paquier wrote:
> > I think I still prefer \bind_named or maybe \bindnamed (depending on
> > what our policy for underscores in \ commands is).
>
> Not sure that there is such a policy in place. I find names with
> underscores easier to parse.
I just double c
On Thu, Jun 19, 2025 at 9:09 AM Michael Paquier wrote:
> Good point. I would be on board with a \close_prepared then, if
> that's the consensus we reach, without touching at \bind_named. We
> still have time to decide on the name until the release, just let's
> make sure to not do a rename multi
On Wed, Jun 18, 2025 at 09:15:07AM +0200, Jelte Fennema-Nio wrote:
> On Wed, 18 Jun 2025 at 08:23, Anthonin Bonnefoy
> wrote:
>> Since \bind_named is also new, we can also rename it to make it
>> consistent with close meta-command. So what about renaming \bind_named
>> to \bindprepared and \close
On Wed, 18 Jun 2025 at 08:23, Anthonin Bonnefoy
wrote:
>
> On Tue, Jun 17, 2025 at 4:05 PM Jelte Fennema-Nio wrote:
> >
> > Agreed. My vote is for \closeprepared as that aligns with the libpq
> > function.
>
> Since \bind_named is also new, we can also rename it to make it
> consistent with clos
On Tue, Jun 17, 2025 at 4:05 PM Jelte Fennema-Nio wrote:
>
> Agreed. My vote is for \closeprepared as that aligns with the libpq function.
Since \bind_named is also new, we can also rename it to make it
consistent with close meta-command. So what about renaming \bind_named
to \bindprepared and \c
On Fri, 13 Jun 2025 at 15:57, Peter Eisentraut wrote:
> That doesn't address the concern that it's confusing what kind of object
> \close operates on. There are named and unnamed cursors (= portals),
> after all.
Agreed. My vote is for \closeprepared as that aligns with the libpq function.
On 13.06.25 04:56, Michael Paquier wrote:
On Thu, Jun 12, 2025 at 09:53:13PM -0400, Greg Sabino Mullane wrote:
On Thu, Jun 12, 2025 at 9:14 AM Peter Eisentraut
wrote:
And this is not something users ever see, so the connection would not be
obvious. Maybe this should be called something more s
On Thu, Jun 12, 2025 at 09:53:13PM -0400, Greg Sabino Mullane wrote:
> On Thu, Jun 12, 2025 at 9:14 AM Peter Eisentraut
> wrote:
>> And this is not something users ever see, so the connection would not be
>> obvious. Maybe this should be called something more specific like
>> \close_stmt.
>
> Ma
On Thu, Jun 12, 2025 at 9:14 AM Peter Eisentraut
wrote:
> And this is not something users ever see, so the connection would not be
> obvious. Maybe this should be called something more specific like
> \close_stmt.
>
Maybe just \closeprepared ?
Cheers,
Greg
--
Crunchy Data - https://www.crunch
On 24.07.24 07:04, Michael Paquier wrote:
This commit introduces three additional commands: \parse, \bindx and
\close.
\parse creates a prepared statement using extended protocol.
\bindx binds and execute an existing prepared statement using extended
protocol.
\close closes an existing prepared s
On 24.07.24 07:04, Michael Paquier wrote:
This commit introduces three additional commands: \parse, \bindx and
\close.
\parse creates a prepared statement using extended protocol.
\bindx binds and execute an existing prepared statement using extended
protocol.
\close closes an existing prepared s
Hi,
> It took me a couple of days to get back to it, but attached is what I
> have finished with. This was mostly OK, except for a few things:
> - \close was inconsistent with the other two commands, where no
> argument was treated as the unnamed prepared statement. I think that
> this should be
On Fri, Jul 19, 2024 at 03:28:44PM +0200, Tomas Vondra wrote:
> OK, if you're already half-way through the review, I'll leave it up to
> you. I don't think we need to rush, and I'd have to learn about all the
> psql stuff first anyway.
It took me a couple of days to get back to it, but attached is
On Fri, Jul 19, 2024 at 03:28:44PM +0200, Tomas Vondra wrote:
> OK, if you're already half-way through the review, I'll leave it up to
> you. I don't think we need to rush, and I'd have to learn about all the
> psql stuff first anyway.
It took me a couple of days to get back to it, but attached is
On 7/19/24 04:23, Michael Paquier wrote:
> On Fri, Jul 19, 2024 at 12:17:44AM +0200, Tomas Vondra wrote:
>> shall we do something about this patch? It seems to be in a pretty good
>> shape (pretty much RFC, based on quick review), the cfbot is still
>> happy, and there seems to be agreement this is
On Fri, Jul 19, 2024 at 12:17:44AM +0200, Tomas Vondra wrote:
> shall we do something about this patch? It seems to be in a pretty good
> shape (pretty much RFC, based on quick review), the cfbot is still
> happy, and there seems to be agreement this is a nice feature.
>
> Michael, I see you've re
Hi,
shall we do something about this patch? It seems to be in a pretty good
shape (pretty much RFC, based on quick review), the cfbot is still
happy, and there seems to be agreement this is a nice feature.
Michael, I see you've reviewed the patch in January. Do you agree / plan
to get it committe
On Fri, 19 Jan 2024 at 10:50, Michael Paquier wrote:
>
> On Thu, Jan 18, 2024 at 09:25:16AM +0100, Anthonin Bonnefoy wrote:
> > From what I can tell, there's no change in the behaviour. All paths
> > would eventually go through HandleSlashCmds's cleaning logic. This is
> > also mentioned in ignore
On Thu, Jan 18, 2024 at 09:25:16AM +0100, Anthonin Bonnefoy wrote:
> From what I can tell, there's no change in the behaviour. All paths
> would eventually go through HandleSlashCmds's cleaning logic. This is
> also mentioned in ignore_slash_options's comment.
Yeah, I can confirm that. I would be
> Hmm. So it does not lead to any user-visible changes, right?
>From what I can tell, there's no change in the behaviour. All paths
would eventually go through HandleSlashCmds's cleaning logic. This is
also mentioned in ignore_slash_options's comment.
* Read and discard "normal" slash command op
On Wed, Jan 17, 2024 at 10:05:33AM +0100, Anthonin Bonnefoy wrote:
> > I do realize the same is true for plain \bind, but it seems
> > like a bug there too.
>
> The unscanned bind's parameters are discarded later in the
> HandleSlashCmds functions. So adding the ignore_slash_options() for
> inacti
> I do realize the same is true for plain \bind, but it seems
> like a bug there too.
The unscanned bind's parameters are discarded later in the
HandleSlashCmds functions. So adding the ignore_slash_options() for
inactive branches scans and discards them earlier. I will add it to
match what's done
On Tue, Jan 16, 2024 at 10:37:22AM +0100, Jelte Fennema-Nio wrote:
> I do realize the same is true for plain \bind, but it seems
> like a bug there too.
Hmm. ignore_slash_options() is used to make the difference between
active and inactive branches with \if. I was playing a bit with
psql.sql but
On Tue, 16 Jan 2024 at 10:37, Jelte Fennema-Nio wrote:
>
> Looks really good now. One thing I noticed is that \bindx doesn't call
> ignore_slash_options if it's not in an active branch. Afaict it
> should. I do realize the same is true for plain \bind, but it seems
> like a bug there too.
To cov
One more usability thing. I think \parse and \close should not require
a \g to send the message. You can do that by returning PSQL_CMD_SEND
instead of PSQL_CMD_SKIP_LIN.
I feel like the main point of requiring \g for \bind and \bindx is so
you can also use \gset or \gexec. But since \parse and \clo
Looks really good now. One thing I noticed is that \bindx doesn't call
ignore_slash_options if it's not in an active branch. Afaict it
should. I do realize the same is true for plain \bind, but it seems
like a bug there too.
Hi,
Thanks for the review and comments.
> One thing that I think should be added for completeness though is the
> ability to deallocate the prepared statement using
> PQsendClosePrepared. Other than that the changes look great.
Good point, I've added the \close command.
> Also a tiny nitpick: st
On Thu, 2 Nov 2023 at 10:52, Anthonin Bonnefoy
wrote:
> The main goal is to provide more ways to test extended protocol in
> regression tests
> similarly to what \bind is doing.
I think this is a great addition. One thing that I think should be
added for completeness though is the ability to deal
Hi all!
Currently, only unnamed prepared statements are supported by psql with the
\bind command and it's not possible to create or use named prepared statements
through extended protocol.
This patch introduces 2 additional commands: \parse and \bindx.
\parse allows us to issue a Parse message to
33 matches
Mail list logo
