On Sat, Jul 8, 2023 at 1:33 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > On Fri, Jul 7, 2023 at 4:13 PM Tom Lane wrote:
> >> The ECPG datetime datatype support code has been basically unmaintained
> >> for years, and has diverged quite far at this point from the core code.
>
> > I was under
Thanks for the new patch.
On Thu, Jul 06, 2023 at 05:58:33PM +0200, Daniel Gustafsson wrote:
>> On 4 Jul 2023, at 21:08, Nathan Bossart wrote:
>> Also, I think it would be worth breaking check_for_data_types_usage() into
>> a few separate functions (or doing some other similar refactoring) to
>>
On 02/07/2023 19:09, Tomas Vondra wrote:
Here's an updated version of the patch series.
I've polished and pushed the first three patches with cleanup, tests to
improve test coverage and so on. I chose not to backpatch those - I
planned to do that to make future backpatches simpler, but the chang
On Sat, Jul 08, 2023 at 04:44:06PM -0400, Joseph Koshakow wrote:
> 2023-07-08 16:33:27.787 EDT [157141] PANIC: ERRORDATA_STACK_SIZE exceeded
> 2023-07-08 16:33:27.882 EDT [156878] LOG: server process (PID 157141) was
> terminated by signal 6: Aborted
> 2023-07-08 16:33:27.882 EDT [156878] DETAIL:
On Sat, Jul 8, 2023 at 6:09 PM Nathan Bossart
wrote:
>> I think the issue here is that if a session loses the ability to set
>> their session authorization in the middle of a transaction, then
>> rolling back the transaction may fail and cause the server to panic.
>> That's probably what the dele
On Sat, Jul 8, 2023 at 10:13 AM Thomas Munro wrote:
> Thanks. I will wait a bit to see if Peter has any other comments and
> then push this. I haven't actually tested with Solution.pm due to
> lack of CI for that, but fingers crossed, since the build systems will
> now agree, reducing the screw-
On Sun, 9 Jul 2023 at 05:28, Tom Lane wrote:
> More generally, it's not clear to me why we should need to look inside
> lateral PHVs in the first place. Wouldn't the lateral PHV itself
> serve fine as a cache key?
For Memoize specifically, I purposefully made it so the expression was
used as a c
On Thu, Jul 6, 2023 at 1:03 AM Peter Eisentraut wrote:
> This looks all pretty good to me. A few more comments:
Thanks for the feedback! New patch attached here. Responses below:
> It seems to me that many of the test cases added in indexing.sql are
> redundant with create_table.sql/alter_table
HI,
Regards,
Zhang Mingli
On Jul 7, 2023, 18:00 +0800, Damir Belyalov , wrote:
>
> The patch does not work for the current version of postgres, it needs to be
> updated.
> I tested your patch. Everything looks simple and works well.
>
> There is a suggestion to simplify the code: instead of using
On Wed, Jul 5, 2023 at 7:45 AM Masahiko Sawada wrote:
>
> On Mon, Jun 19, 2023 at 5:29 PM Peter Smith wrote:
> >
> > Hi,
> >
> > Below are my review comments for the PoC patch 0001.
> >
> > In addition, the patch needed rebasing, and, after I rebased it
> > locally in my private environment ther
On Sat, 8 Jul 2023 at 17:24, Paul A Jungwirth
wrote:
> One adjacent thing I noticed is that when we renamed "Result Cache" to
> "Memoize" this bit of the docs in config.sgml got skipped (probably
> because of the line break):
>
> Hash tables are used in hash joins, hash-based aggregation,
On Fri, Jul 07, 2023 at 01:49:24PM +0900, Michael Paquier wrote:
> Hmm. If we go down this road I would make the choice of simplicity
> and remove entirely a column, then, generating the snakecase from the
> camelcase or vice-versa (say like a $string =~ s/([a-z]+)/$1_/g;),
> even if it means havi
On Sat, Jul 08, 2023 at 07:08:35PM -0400, Joseph Koshakow wrote:
> On Sat, Jul 8, 2023 at 6:09 PM Nathan Bossart
> wrote:
>
>>> I think the issue here is that if a session loses the ability to set
>>> their session authorization in the middle of a transaction, then
>>> rolling back the transactio
On 07.07.23 22:30, Thomas Munro wrote:
Thinking about how to bring this all into "normal" form -- where
HAVE_XXX means "system defines XXX", not "system defines XXX || we
define a replacement"
HAVE_XXX means "code can use XXX", doesn't matter how it got there (it
could also be a libpgport repl
On Sun, Jul 9, 2023 at 6:20 PM Peter Eisentraut wrote:
> So I don't think this code is correct. AFAICT, there is nothing right
> now that can possibly define HAVE_MBSTOWCS_L on Windows/MSVC. Was that
> the intention?
Yes, that was my intention. Windows actually doesn't have them. The
autoconf
On 03.07.23 11:53, Peter Eisentraut wrote:
On 23.03.23 02:45, Anatoly Zaretsky wrote:
Comments in src/backend/libpq/auth.c [1] say:
(after successfully finding the final DN to check the user-supplied
password against)
/* Unbind and disconnect from the LDAP server */
and later
/*
* Need to re-i
Well, one option would be to modify all selectivity functions to do
something like the patch does for nulltestsel(). That seems a bit
cumbersome because why should those places care about maybe running on
the outer side of a join, or what? For code in extensions this would be
particularly probl
On 7/8/23 10:29, Alena Rybakina wrote:
>
>> Well, one option would be to modify all selectivity functions to do
>> something like the patch does for nulltestsel(). That seems a bit
>> cumbersome because why should those places care about maybe running on
>> the outer side of a join, or what? Fo
On 2023-07-06 Th 12:38, Andrew Dunstan wrote:
On 2023-07-06 Th 09:50, Daniel Gustafsson wrote:
On 5 Jul 2023, at 14:49, Andrew Dunstan wrote:
On 2023-07-04 Tu 16:54, Daniel Gustafsson wrote:
On 4 Jul 2023, at 20:19, Andrew Dunstan
wrote:
But sadly we're kinda back where we started. fairy
Sergey Shinderuk writes:
> While analyzing -Wclobbered warnings from gcc we found a true one in
> PostgresMain():
> ...
> These variables must be declared volatile, because they are read after
> longjmp(). send_ready_for_query declared there is volatile.
Yeah, you're on to something there.
> W
On 2023-07-08 Sa 09:15, Andrew Dunstan wrote:
On 2023-07-06 Th 12:38, Andrew Dunstan wrote:
On 2023-07-06 Th 09:50, Daniel Gustafsson wrote:
On 5 Jul 2023, at 14:49, Andrew Dunstan wrote:
On 2023-07-04 Tu 16:54, Daniel Gustafsson wrote:
On 4 Jul 2023, at 20:19, Andrew Dunstan
wrote:
B
I wrote:
> So I end up with the attached. I went ahead and dropped
> ArrayGetOffset0() as part of 0001, and I split 0002 into two patches
> where the new 0002 avoids re-indenting any existing code in order
> to ease review, and then 0003 is just a mechanical application
> of pgindent.
That got si
Pavel Luzanov writes:
> Please find attached new patch version.
> It implements \drg command and hides duplicates in \du & \dg commands.
I took a quick look through this, and have some minor suggestions:
1. I was thinking in terms of dropping the "Member of" column entirely
in \du and \dg. It d
Jacob Champion writes:
> Hi Joe, here's a partial review:
Thanks so much for the review!
> I'm new to this code, but I agree that the use of `type` and the
> lookahead are not particularly obvious/intuitive. At the very least,
> they'd need some more explanation in the code. Your boolean flag id
Richard Guo writes:
> Rebase the patch on HEAD as cfbot reminds.
This fix seems like a mess. The function that is in charge of filling
RelOptInfo.lateral_vars is extract_lateral_references; or at least
that was how it was done up to now. Can't we compute these additional
references there? If n
Ashutosh Bapat writes:
> Fixed assertion in time_mi_time(). It needed to assert that the result
> is FINITE but it was doing the other way round and that triggered some
> failures in cfbot.
It's still not passing in the cfbot, at least not on any non-Linux
platforms. I believe the reason is that
Nathan Bossart wrote:
> I see that RESET SESSION AUTHORIZATION
> with a concurrently dropped role will FATAL with your patch but succeed
> without it, which could be part of the reason.
I didn't even realize it, but the change to superuser_arg() in v2 fixed
this issue. The catalog lookup is only
I wrote:
> That got sideswiped by ae6d06f09, so here's a trivial rebase to
> pacify the cfbot.
Sigh, this time with patch.
regards, tom lane
From 63ee707f6aa38043c0211c0c4a124fa5fe2ad016 Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Sat, 8 Jul 2023 11:55:56 -0400
Subject
On 08/07/2023 19:08, Tom Lane wrote:
I wrote:
So I end up with the attached. I went ahead and dropped
ArrayGetOffset0() as part of 0001, and I split 0002 into two patches
where the new 0002 avoids re-indenting any existing code in order
to ease review, and then 0003 is just a mechanical applica
On Fri, Jul 7, 2023 at 4:13 PM Tom Lane wrote:
>
> The ECPG datetime datatype support code has been basically unmaintained
> for years, and has diverged quite far at this point from the core code.
I was under the impression that anything in the postgresql.git
repository is considered core, and he
Heikki Linnakangas writes:
> On 08/07/2023 19:08, Tom Lane wrote:
>> That got sideswiped by ae6d06f09, so here's a trivial rebase to
>> pacify the cfbot.
> Something's wrong with your attachments.
Yeah, I forgot to run mhbuild :-(
> I spent some time today refactoring it for readability and spe
On 08/07/2023 22:49, Tom Lane wrote:
BTW, what's your opinion of allowing "[1:0]={}" ? Although that was
my proposal to begin with, I'm having second thoughts about it now.
The main reason is that the input transformation would be lossy,
eg "[1:0]={}" and "[101:100]={}" would give the same resul
Gurjeet Singh writes:
> On Fri, Jul 7, 2023 at 4:13 PM Tom Lane wrote:
>> The ECPG datetime datatype support code has been basically unmaintained
>> for years, and has diverged quite far at this point from the core code.
> I was under the impression that anything in the postgresql.git
> reposito
I've discovered an issue with this approach. Let's say you have some
session open that is connected as a superuser and you run the following
commands:
- CREATE ROLE r1 LOGIN SUPERUSER;
- CREATE ROLE r2;
- CREATE ROLE r3;
Then you open another session connected with user r1 and run the
follo
34 matches
Mail list logo
