hi.
while reading this[1],
<< More information about partial indexes can be found in [ston89b],
[olson93], and [seshadri95].
I googled around, still cannot find [olson93] related pdf or html link.
in [2],
I found out
[ong90] “A Unified Framework for Version Modeling Using Production
Rules in a
On Mon, May 13, 2024 at 11:22:08AM +0200, Daniel Gustafsson wrote:
> Since json (and yaml/xml) is intended to be machine-readable I think we use a
> single unit for all values, and document this fact.
Agreed with the documentation gap. Another thing that could be worth
considering is to add the
On Tue, May 14, 2024 at 7:30 AM Paul Jungwirth
wrote:
>
> On 5/13/24 03:11, Peter Eisentraut wrote:
> > It looks like we missed some of these fundamental design questions early
> > on, and it might be too
> > late now to fix them for PG17.
> >
> > For example, the discussion on unique
On Mon, May 13, 2024 at 01:01:21PM +0300, Aleksander Alekseev wrote:
>> Any objections to fixing this in 17 by removing it? (cc:ing Michael from the
>> RMT)
>
> +1 Something that is not documented or used by anyone (apparently) and
> is broken should just be removed.
8a02339e9ba3 sounds like an
Hi Kuroda-san, Here are some review comments for all patches v9*
//
Patch v9-0001
//
There were no changes since v8-0001, so no comments.
//
Patch v9-0002
//
==
Commit Message
2.1.
Regarding the off->on case, the logical replication already has a
mechanism
On Fri, 15 Mar 2024 at 10:13, Tomas Vondra
wrote:
> To clarify, I think the patch is a step in the right direction, and a
> meaningful improvement. It may not be the perfect solution we imagine
> (but who knows how far we are from that), but AFAIK moving these
> decisions to the node level is
Hi Kuroda-san,
I'm having second thoughts about how these patches mention the option
values "on|off". These are used in the ALTER SUBSCRIPTION document
page for 'two_phase' and 'failover' parameters, and then those
"on|off" get propagated to the code comments, error messages, and
tests...
Now I
>> Consider join of tables "a", "b" and "c". My understanding is that
>> make_join_rel() is called once with rel1={a} and rel2={b join c}, then with
>> rel1={a join b} and rel2={c}, etc. I wanted to say that each call should
>> produce the same set of unique keys.
>>
>> I need to check this
Antonin Houska writes:
>> Could you make the reason clearer for adding 'List *opfamily_lists;'
>> into UniqueKey? You said "This is needed to create ECs in the parent
>> query if the upper relation represents a subquery." but I didn't get the
>> it. Since we need to maintain the UniqueKey in
I noticed that we (kind of) accept underscores in positional parameters.
For example, this works:
=> PREPARE p1 AS SELECT $1_2;
PREPARE
=> EXECUTE p1 (123);
?column?
--
123
(1 row)
Parameter $1_2 is taken as $1 because in rule {param} in scan.l we get
the
Bruce Momjian writes:
> On Sat, May 11, 2024 at 01:27:25PM +0800, Andy Fan wrote:
>>
>> Hello Bruce,
>>
>> > I have committed the first draft of the PG 17 release notes; you can
>> > see the results here:
>> >
>> >https://momjian.us/pgsql_docs/release-17.html
>>
>> Thank you for
jian he 于2024年5月9日周四 18:00写道：
> On Thu, May 9, 2024 at 12:04 PM Bruce Momjian wrote:
> >
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
> >
>
> another potential incompatibilities
On Sat, May 11, 2024 at 01:27:25PM +0800, Andy Fan wrote:
>
> Hello Bruce,
>
> > I have committed the first draft of the PG 17 release notes; you can
> > see the results here:
> >
> > https://momjian.us/pgsql_docs/release-17.html
>
> Thank you for working on this!
>
> > I welcome
On Sat, May 11, 2024 at 10:24:39AM -0400, Joe Conway wrote:
> On 5/11/24 09:57, Jelte Fennema-Nio wrote:
> > On Fri, 10 May 2024 at 23:31, Tom Lane wrote:
> > >
> > > Bruce Momjian writes:
> > > > I looked at both of these. In both cases I didn't see why the user
> > > > would need to know
On Tue, May 14, 2024 at 8:17 AM Tom Lane wrote:
> I'm not sure whether we've got unsent data pending in the problematic
> condition, nor why it'd remain unsent if we do (shouldn't the backend
> consume it anyway?). But this has the right odor for an explanation.
>
> I'm pretty hesitant to touch
On Fri, May 10, 2024 at 05:31:33PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, May 10, 2024 at 06:50:54PM +0200, Jelte Fennema-Nio wrote:
> >> There are two commits that I think would benefit from being listed
> >> (but maybe they are already listed and I somehow missed them, or
On Thu, Apr 25, 2024 at 02:53:33PM +0200, Majid Garoosi wrote:
> Unfortunately, I quit that company a month ago (I wish we could
> discuss this earlier) and don't have access to the environment
> anymore.
> I'll try to ask my teammates and see if they can find anything about
> the exact values of
On Tue, 14 May 2024 at 06:18, Juan Hernández wrote:
> Do you consider useful to add a parameter (for example, --separatetables) so
> when used the exporting file process can create a different tablename.sql
> file for each table in database automatically?
>
> Example...
>
> PGHOST="/tmp"
Hello,
> When the checkpointer process is busy, even if we reset
> synchronous_standby_names, the resumption of the backend processes waiting in
> SyncRep are made to wait until the checkpoint is completed.
> This prevents the prompt resumption of application processing when a problem
> occurs
[this should probably belong to a different thread, but I'm not sure
what to title it]
On Mon, May 13, 2024 at 4:08 AM Heikki Linnakangas wrote:
> I think these options should be designed from the user's point of view,
> so that the user can specify the risks they're willing to accept, and
> the
On 5/13/24 03:11, Peter Eisentraut wrote:
It looks like we missed some of these fundamental design questions early on, and it might be too
late now to fix them for PG17.
For example, the discussion on unique constraints misses that the question of null values in unique
constraints itself is
David Rowley writes:
> I've not seen any recent failures from Parula that relate to this
> issue. The last one seems to have been about 4 weeks ago.
> I'm now wondering if it's time to revert the debugging code added in
> 1db689715. Does anyone think differently?
+1. It seems like we wrote
On Mon, May 13, 2024 at 07:11:53PM GMT, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-05-13 19:25:11 -0300, Fabrízio de Royes Mello wrote:
> >> Hmmm, depending on the extension it can extensively call/use postgres code
> >> so would be nice if we can differentiate if the code is called from
Hi,
On 2024-05-13 19:11:53 -0400, Tom Lane wrote:
> The mechanism that Andres describes for sourcing the name seems a bit
> overcomplex though. Why not just allow/require each extension to
> specify its name as a constant string? We could force the matter by
> redefining PG_MODULE_MAGIC as
On Thu, 21 Mar 2024 at 13:53, David Rowley wrote:
>
> On Thu, 21 Mar 2024 at 12:36, Tom Lane wrote:
> > So yeah, if we could have log_autovacuum_min_duration = 0 perhaps
> > that would yield a clue.
>
> FWIW, I agree with your earlier statement about it looking very much
> like auto-vacuum has
Andres Freund writes:
> On 2024-05-13 19:25:11 -0300, Fabrízio de Royes Mello wrote:
>> Hmmm, depending on the extension it can extensively call/use postgres code
>> so would be nice if we can differentiate if the code is called from
>> Postgres itself or from an extension.
> I think that's not
Hi,
On 2024-05-13 19:25:11 -0300, Fabrízio de Royes Mello wrote:
> On Mon, May 13, 2024 at 5:51 PM Andres Freund wrote:
> > It's not entirely trivial to provide errfinish() with a parameter
> indicating
> > the extension, but it's doable:
> >
> > 1) Have PG_MODULE_MAGIC also define a new
On Mon, May 13, 2024 at 9:13 AM Robert Haas wrote:
> I find this idea to be a massive improvement over the status quo,
+1
> and
> I didn't spot any major problems when I read through the patch,
> either.
Definitely not a major problem, but I think
select_next_encryption_method() has gone
On Mon, May 13, 2024 at 5:51 PM Andres Freund wrote:
>
> Hi,
>
> It can be very useful to look at the log messages emitted by a larger
number
> of postgres instances to see if anything unusual is happening. E.g.
checking
> whether there are an increased number of internal, IO, corruption errors
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Hi,
It can be very useful to look at the log messages emitted by a larger number
of postgres instances to see if anything unusual is happening. E.g. checking
whether there are an increased number of internal, IO, corruption errors (and
LOGs too, because we emit plenty bad things as LOG) . One
On 06.03.24 22:54, Thomas Munro wrote:
Rebased. I had intended to try to get this into v17, but a couple of
unresolved problems came up while rebasing over the new incremental
backup stuff. You snooze, you lose. Hopefully we can sort these out
in time for the next commitfest:
* should
Hello,
In light of multiple threads [1-6] discussing sorting improvements, I'd like to
consolidate the old (+some new) ideas as a starting point.
It might make sense to brain storm on a few of these ideas and maybe even
identify some that are worth implementing and testing.
1. Simple
On Mon, May 13, 2024 at 03:53:08PM -0400, Robert Haas wrote:
> On Sun, May 12, 2024 at 7:29 PM Noah Misch wrote:
> > - [consequences limited to transient failure] Since a PROC_IN_VACUUM
> > backend's
> > xmin does not stop pruning, an MVCC scan in that backend can find zero
> > tuples when
On Mon, May 13, 2024 at 11:14 AM Frédéric Yhuel
wrote:
> FWIW, I do agree with your math. I found your demonstration convincing.
> 50 was selected with the wet finger.
Good to know.
> Using the formula I suggested earlier:
>
> vacthresh = Min(vac_base_thresh + vac_scale_factor * reltuples,
Thomas Munro writes:
> For citext_utf8, I pushed cff4e5a3. Hamerkop runs infrequently, so
> here's hoping for 100% green on master by Tuesday or so.
In the meantime, some off-list investigation by Alexander Lakhin
has turned up a good deal of information about why we're seeing
failures on
On Sun, May 12, 2024 at 7:29 PM Noah Misch wrote:
> - [consequences limited to transient failure] Since a PROC_IN_VACUUM backend's
> xmin does not stop pruning, an MVCC scan in that backend can find zero
> tuples when one is live. This is like what all backends got in the days of
>
On Mon, May 13, 2024 at 10:53 AM Matthias van de Meent
wrote:
> It's not inconceivable that this will significantly increase WAL
> volume, but I think we should go for correctness rather than fastest
> copy.
I don't think we can afford to just do this blindly for the sake of a
hypothetical
On Mon, May 13, 2024 at 1:42 PM Jelte Fennema-Nio wrote:
> Like Jacob already said, I guess you meant me here. The main point I
> was trying to make is that sslmode=require is extremely insecure too,
> so if we're changing the default then I'd rather bite the bullet and
> actually make the
On Mon, May 13, 2024 at 12:45 PM Jacob Champion
wrote:
> For the record, I didn't say that... You mean Jelte's quote up above?
Yeah, sorry, I got my J-named hackers confused. Apologies.
--
Robert Haas
EDB: http://www.enterprisedb.com
On 05/13/24 09:35, aa wrote:
> If you call the action of "sifting" ordering, then yes. If you don't call
> it ordering, then no.
One thing seems intriguing about this idea: normally, an expected
property of any ORDER BY is that no result row can be passed down
the pipe until all input rows have
On Mon, May 13, 2024 at 12:45 PM Alvaro Herrera wrote:
> The point is that a column can be in a primary key and not have an
> explicit not-null constraint. This is different from having a column be
> NOT NULL and having a primary key on top. In both cases the attnotnull
> flag is set; the
On Mon, May 13, 2024 at 04:59:59PM +0900, Michael Paquier wrote:
> About inplace050-tests-inj-v1.patch.
>
> + /* Check if blocked_pid is in injection_wait(). */
> + proc = BackendPidGetProc(blocked_pid);
> + if (proc == NULL)
> + PG_RETURN_BOOL(false); /* session gone:
aa writes:
> If you call the action of "sifting" ordering, then yes. If you don't call
> it ordering, then no.
> In essence, is the output of a filtering mechanism, done in a single result
> set pass. And this pass should be the same pass in charge of collecting the
> result set in the first
Hi,
If you call the action of "sifting" ordering, then yes. If you don't call
it ordering, then no.
In essence, is the output of a filtering mechanism, done in a single result
set pass. And this pass should be the same pass in charge of collecting the
result set in the first place.
Thanks
On
Hi team!
First, i want to thank you for having your hands in this. You are doing a
fantastic and blessing job. Bless to you all!
I have a special need i want to comment to you. This is not a bug, is a
need i have and i write here for been redirected where needed.
I have to make a daily backup.
[soapbox thread, so I've changed the Subject]
On Mon, May 13, 2024 at 4:08 AM Heikki Linnakangas wrote:
> "channel_binding=require sslmode=require" also protects from MITM attacks.
This isn't true in the same way that "standard" TLS protects against
MITM. I know you know that, but for the
> On 13 May 2024, at 20:05, Ranier Vilela wrote:
> Em qua., 10 de abr. de 2024 às 15:33, Daniel Gustafsson
> escreveu:
> Thanks, I'll have a look. I've left this for post-freeze on purpose to not
> cause unnecessary rebasing. Will take a look over the next few days unless
> beaten to it.
>
Em qua., 10 de abr. de 2024 às 15:33, Daniel Gustafsson
escreveu:
> On 10 Apr 2024, at 20:31, Ranier Vilela wrote:
>
> Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson
> escreveu:
>
>> > On 2 Apr 2024, at 20:13, Ranier Vilela wrote:
>>
>> > Fix by freeing the pointer, like pclose_check
Em seg., 13 de mai. de 2024 às 14:38, Tom Lane escreveu:
> David Rowley writes:
> > I've added a CF entry under your name for this:
> > https://commitfest.postgresql.org/48/4927/
>
> > If it was code new to PG17 I'd be inclined to go ahead with it now,
> > but it does not seem to align with
Antonin Houska wrote:
> Andy Fan wrote:
> > >
> > > * Combining the UKs
> > >
> > > IMO this is the most problematic part of the patch. You call
> > > populate_joinrel_uniquekeys() for the same join multiple times,
> >
> > Why do you think so? The below code is called in "make_join_rel"
>
On Mon, 13 May 2024 at 18:14, Robert Haas wrote:
> I disagree with Jacob's assertion that sslmode=require has no security
> benefits over sslmode=prefer. That seems like the kind of pessimism
> that makes people hate security professionals. There have got to be
> some attacks that are foreclosed
David Rowley writes:
> I've added a CF entry under your name for this:
> https://commitfest.postgresql.org/48/4927/
> If it was code new to PG17 I'd be inclined to go ahead with it now,
> but it does not seem to align with making the release mode stable.
> I'd bet others will feel differently
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> I'm fairly down on this idea for SQL, because I think it creates
>> ambiguity for the ROW() constructor syntax. That is:
>> (x,y) is understood to be shorthand for ROW(x,y)
>> (x) is not ROW(x), it's just x
>>
[ I got distracted while writing this follow-up and only just found it
in my list of unsent Gnus buffers, and now it's probably too late to
make it for 17, but here it is anyway while I remember. ]
Tom Lane writes:
> I happened to notice that information_schema._pg_expandarray(),
> which
On 2024-May-13, Robert Haas wrote:
> On Mon, May 13, 2024 at 9:44 AM Alvaro Herrera
> wrote:
> > The problematic point is the need to add NOT NULL constraints during
> > table creation that don't exist in the table being dumped, for
> > performance of primary key creation -- I called this a
(There's, uh, a lot to respond to above and I'm trying to figure out
how best to type up all of it.)
On Mon, May 13, 2024 at 9:13 AM Robert Haas wrote:
> However,
> I disagree with Jacob's assertion that sslmode=require has no security
> benefits over sslmode=prefer.
For the record, I didn't
Tom Lane writes:
> =?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
>> Matthias van de Meent writes:
>>> Single trailing commas are a feature that's more and more common in
>>> languages, yes, but arbitrary excess commas is new to me. Could you
>>> provide some examples of popular languages
On Mon, May 13, 2024 at 9:37 AM Heikki Linnakangas wrote:
> On 10/05/2024 16:50, Heikki Linnakangas wrote:
> > New proposal:
> >
> > - Remove the "try both" mode completely, and rename "requiredirect" to
> > just "direct". So there would be just two modes: "postgres" and
> > "direct". On
On Mon, May 13, 2024 at 05:43:45PM +0200, Alvaro Herrera wrote:
> Can't we add these two lines per topic to the README.md?
That would be fine with me, too. The multiple-files approach is perhaps a
bit more tailored to GitHub, but there's something to be said for keeping
this information
On 2024-May-13, Nathan Bossart wrote:
> > If we want to enhance the GitHub experience, we can also add these files to
> > the organization instead:
> > https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file
>
> This was
On Sun, May 12, 2024 at 05:17:42PM +0200, Peter Eisentraut wrote:
> I don't know, I find these files kind of "yelling". It's fine to have a
> couple, but now it's getting a bit much, and there are more that could be
> added.
I'm not sure what you mean by this. Do you mean that the contents are
On Mon, May 13, 2024 at 9:44 AM Alvaro Herrera wrote:
> The problematic point is the need to add NOT NULL constraints during
> table creation that don't exist in the table being dumped, for
> performance of primary key creation -- I called this a throwaway
> constraint. We needed to be able to
Le 09/05/2024 à 16:58, Robert Haas a écrit :
As I see it, a lot of the lack of agreement up until now is people
just not understanding the math. Since I think I've got the right idea
about the math, I attribute this to other people being confused about
what is going to happen and would tend
On 13/05/2024 16:55, Jelte Fennema-Nio wrote:
On Mon, 13 May 2024 at 15:38, Heikki Linnakangas wrote:
Here's a patch to implement that.
+ if (conn->sslnegotiation[0] == 'd' &&
+ conn->sslmode[0] != 'r' && conn->sslmode[0] != 'v')
I think these checks should use strcmp
On Mon, 13 May 2024 at 16:13, Tom Lane wrote:
>
> Matthias van de Meent writes:
> > PFA a patch that fixes this issue, by assuming that all pages in the
> > source database utilize a non-standard page layout.
>
> Surely that cure is worse than the disease?
I don't know where we would get the
On Mon, 13 May 2024 at 04:40, aa wrote:
> Hello Everyone!
>
> Is there any chance to get some kind of a result set sifting mechanism in
> Postgres?
>
> What I am looking for is a way to get for example: "nulls last" in a
> result set, without having to call "order by" or having to use UNION ALL,
On Mon, 13 May 2024 at 13:07, Heikki Linnakangas wrote:
> "channel_binding=require sslmode=require" also protects from MITM attacks.
Cool, I didn't realize we had this connection option and it could be
used like this. But I think there's a few security downsides of
channel_binding=require over
On 2024-05-12 Su 18:05, Thomas Munro wrote:
On Mon, May 13, 2024 at 12:26 AM Andrew Dunstan wrote:
Well, this is more or less where I came in back in about 2002 :-) I've been
trying to help support it ever since, mainly motivated by stubborn persistence
than anything else. Still, I agree
Matthias van de Meent writes:
> PFA a patch that fixes this issue, by assuming that all pages in the
> source database utilize a non-standard page layout.
Surely that cure is worse than the disease?
regards, tom lane
On Fri, Apr 19, 2024 at 1:32 PM Nazir Bilal Yavuz wrote:
>
> > I wanted to inform you that the 73f0a13266 commit changed all WALRead
> > calls to read variable bytes, only the WAL receiver was reading
> > variable bytes before.
>
> I want to start working on this again if possible. I will try to
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Matthias van de Meent writes:
>> Single trailing commas are a feature that's more and more common in
>> languages, yes, but arbitrary excess commas is new to me. Could you
>> provide some examples of popular languages which have that, as I
On Sat, May 11, 2024 at 3:18 PM Tomas Vondra
wrote:
>
> On 5/10/24 21:48, Melanie Plageman wrote:
> > Attached is v3. I didn't use your exact language because the test
> > wouldn't actually verify that we properly discard the tuples. Whether
> > or not the empty tuples are all emitted, it just
On Mon, 13 May 2024 at 15:38, Heikki Linnakangas wrote:
> Here's a patch to implement that.
+ if (conn->sslnegotiation[0] == 'd' &&
+ conn->sslmode[0] != 'r' && conn->sslmode[0] != 'v')
I think these checks should use strcmp instead of checking magic first
characters. I see this
On 2024-May-13, Robert Haas wrote:
> On Sat, May 11, 2024 at 5:40 AM Alvaro Herrera
> wrote:
> > Specifically, the problem is that I mentioned that we could restrict the
> > NOT NULL NO INHERIT addition in pg_dump for primary keys to occur only
> > in pg_upgrade; but it turns this is not
On 10/05/2024 16:50, Heikki Linnakangas wrote:
New proposal:
- Remove the "try both" mode completely, and rename "requiredirect" to
just "direct". So there would be just two modes: "postgres" and
"direct". On reflection, the automatic fallback mode doesn't seem very
useful. It would make sense
Hi,
On Fri, 10 May 2024 at 19:09, Masahiko Sawada wrote:
>
> On Fri, May 10, 2024 at 7:26 PM Nazir Bilal Yavuz wrote:
> >
> > Hi,
> >
> > Thank you for working on this!
> >
> > On Wed, 1 May 2024 at 06:37, Masahiko Sawada wrote:
> > >
> > > Thank you for further testing! I've pushed the patch.
On Sat, May 11, 2024 at 5:40 AM Alvaro Herrera wrote:
> I have found two more problems that I think are going to require some
> more work to fix, so I've decided to cut my losses now and revert the
> whole. I'll come back again in 18 with these problems fixed.
Bummer, but makes sense.
>
Hi,
My collegue Konstantin Knizhnik pointed out that we fail to mark pages
with a non-standard page layout with page_std=false in
RelationCopyStorageUsingBuffer when we WAL-log them. This causes us to
interpret the registered buffer as a standard buffer, and omit the
hole in the page, which for
Matthias van de Meent writes:
> On Mon, 13 May 2024 at 10:42, Artur Formella
> wrote:
>> Motivation:
>> Commas of this type are allowed in many programming languages, in some
>> it is even recommended to use them at the ends of lists or objects.
>
> Single trailing commas are a feature that's
Dear Peter,
Thanks for giving comments! New patch was posted in [1].
> 0.1 General - Patch name
>
> /SUBSCIRPTION/SUBSCRIPTION/
Fixed.
> ==
> 0.2 General - Apply
>
> FYI, there are whitespace warnings:
>
> git
> apply ../patches_misc/v8-0004-Add-force_alter-option-for-ALTER-SUBSCIRPTI
>
Dear Peter,
Thanks for reviewing! Patch can be available in [1].
> ==
> src/sgml/ref/alter_subscription.sgml
>
> 1.
> +
> + The two_phase parameter can only be altered when
> the
> + subscription is disabled. When altering the parameter from
> on
> + to off, the backend
1. In the case of parallel workers the plan_rows value has a different semantics than the number of rows predicted. Just explore
get_parallel_divisor().
2. The extension recommends new statistics immediately upon an error finding. But what if the reason for the error is stale statistics? Or
A correction of a typo in previous message:
non-leaf pages iteration cycles (under P_ISLEAF(topaque)) -> non-leaf pages
iteration cycles (under !P_ISLEAF(topaque))
On Mon, 13 May 2024 at 16:19, Pavel Borisov wrote:
>
>
> On Mon, 13 May 2024 at 15:55, Pavel Borisov
> wrote:
>
>> Hi, Alexander!
On Mon, 13 May 2024 at 15:55, Pavel Borisov wrote:
> Hi, Alexander!
>
> On Mon, 13 May 2024 at 05:42, Alexander Korotkov
> wrote:
>
>> On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
>> wrote:
>> > On Sat, May 11, 2024 at 4:13 AM Mark Dilger
>> > wrote:
>> > > > On May 10, 2024, at 12:05
Hi,
As a developer, I love this feature.
But as a developer of an universal TDOP SQL parser[1], this can be a
pain. Please request it to the standard.
Regards,
Étienne
[1]: https://gitlab.com/dalibo/transqlate
Hi, Alexander!
On Mon, 13 May 2024 at 05:42, Alexander Korotkov
wrote:
> On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
> wrote:
> > On Sat, May 11, 2024 at 4:13 AM Mark Dilger
> > wrote:
> > > > On May 10, 2024, at 12:05 PM, Alexander Korotkov <
> aekorot...@gmail.com> wrote:
> > > >
On 13/05/2024 12:50, Jelte Fennema-Nio wrote:
On Sun, 12 May 2024 at 23:39, Heikki Linnakangas wrote:
In v18, I'd like to make sslmode=require the default. Or maybe introduce
a new setting like "encryption=ssl|gss|none", defaulting to 'ssl'. If we
want to encourage encryption, that's the right
> On 13 May 2024, at 10:48, Peter Eisentraut wrote:
> Patches attached.
All patches look good.
> I think the first one is a bug fix.
Agreed.
--
Daniel Gustafsson
Hi,
Bookworm versions of the Debian CI images are available now [0]. The
patches to use these images are attached.
'v1-0001-Upgrade-Debian-CI-images-to-Bookworm_REL_16+.patch' patch can
be applied to both upstream and REL_16 and all of the tasks finish
successfully.
On Mon, May 13, 2024 at 12:45 PM Dmitry Koval wrote:
> 13.05.2024 11:45, Daniel Gustafsson пишет:
> > Commit 3ca43dbbb67f which adds the permission checks seems to cause
> > conflicts
> > in the pg_upgrade tests
>
> Thanks!
>
> It will probably be enough to rename the roles:
>
>
Hi,
> > Thanks. I see a few pieces of code that use special FOO_NUMBER enum
> > values instead of a macro. Should we refactor these pieces
> > accordingly? PFA another patch.
>
> I think this is a sensible improvement.
>
> But please keep the trailing commas on the last enum items.
Thanks,
On 03.04.24 07:30, Paul Jungwirth wrote:
But is it *literally* unique? Well two identical keys, e.g. (5,
'[Jan24,Mar24)') and (5, '[Jan24,Mar24)'), do have overlapping ranges,
so the second is excluded. Normally a temporal unique index is *more*
restrictive than a standard one, since it
Hi,
> Searching the archives I was unable to find any complaints, and this has been
> broken for the entire window of supported releases, so I propose we remove it
> as per the attached patch. If anyone is keen on making this work again for
> all
> the types where it makes sense, it can be
Andy Fan wrote:
> > * I think that, before EC is considered suitable for an UK, its
> > ec_opfamilies
> > field needs to be checked. I try to do that in
> > find_ec_position_matching_expr(), see 0004.
>
> Could you make the reason clearer for adding 'List *opfamily_lists;'
> into
On Sun, 12 May 2024 at 23:39, Heikki Linnakangas wrote:
> You might miss that by changing sslnegotiation to 'postgres', or by
> removing it altogether, you not only made it compatible with older
> server versions, but you also allowed falling back to a plaintext
> connection. Maybe you're fine
On 13/05/2024 00:39, Tom Lane wrote:
Hm. It occurs to me that there *is* a system-specific component to
the amount of WAL emitted during initdb: the number of locales
that "locale -a" prints translates directly to the number of
rows inserted into pg_collation. [...]
Yes. Another
Hi,
do I interpret your idea correctly: You want some sort of ordering without
ordering?
Kind regardsWW
Am Montag, 13. Mai 2024 um 10:40:38 MESZ hat aa
Folgendes geschrieben:
Hello Everyone!
Is there any chance to get some kind of a result set sifting mechanism in
Postgres?
What I
Hi!
13.05.2024 11:45, Daniel Gustafsson пишет:
Commit 3ca43dbbb67f which adds the permission checks seems to cause conflicts
in the pg_upgrade tests
Thanks!
It will probably be enough to rename the roles:
regress_partition_merge_alice -> regress_partition_split_alice
On Mon, 13 May 2024 at 10:42, Artur Formella wrote:
> Motivation:
> Commas of this type are allowed in many programming languages, in some
> it is even recommended to use them at the ends of lists or objects.
Single trailing commas are a feature that's more and more common in
languages, yes, but
1 - 100 of 118 matches
Mail list logo
