itten applications, but it will
only help in certain cases and hurts in many others.
Yours,
Laurenz Albe
subplan, with the correlation vars as the
> cache key.
I like the idea.
I think the cache should be limited in size, perhaps by work_mem.
Also, there probably should be a GUC for this, defaulting to "off".
Yours,
Laurenz Albe
gs nothing.
The attached patch would take care of it, but I'm not sure
if that's the right place to check.
Yours,
Laurenz AlbeFrom d474e7b41298944e43bb9141eb33adbdd9ea1098 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 22 May 2018 18:13:31 +0200
Subject: [PATCH] Don't log
uild the .bc from.
I have been bitten by that when building PostGIS.
A simple patch could fix it, but I agree that it would be better
to not build them.
Yours,
Laurenz Albe
I am worried that there might be loads of Windows installations out there
happily
running productive databases with an unsafe setup, so I'd even suggest
backpatching
such a change.
Yours,
Laurenz Albe
Amit Kapila wrote:
> On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe wrote:
> > I recently read our documentation about reliability on Windows:
> >
> > > On Windows, if wal_sync_method is open_datasync (the default), write
> > > caching can
> > > be dis
Amit Kapila wrote:
> On Fri, Jun 1, 2018 at 8:18 PM, Laurenz Albe wrote:
> > Amit Kapila wrote:
> > > On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe
> > > wrote:
> > > > I recently read our documentation about reliability on Windows:
> > >
t;
> Thoughts?
I thought of a better way.
pg_test_fsync is properly listed as a server application in the documentation,
so I think it should be built as such, as per the attached patch.
Yours,
Laurenz AlbeFrom 032a0463072097e489f912337ea08f7373a4f107 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
D
Alvaro Herrera wrote:
> On 2018-Mar-01, Laurenz Albe wrote:
>
> > I noticed that commit 25fff40798fc4ac11a241bfd9ab0c45c085e2212 forgot
> > to teach SHOW ALL to show all GUCs when the user belongs to
> > pg_read_all_settings.
> >
> > Patch attached; I think t
and sorry for my long silence.
If I remove the "#ifndef FRONTEND", building with MSVC fails for all
call sites that use the two-argument version of open(2).
If I use the three-argument version throughout, which should be no problem,
PostgreSQL builds just fine with MSVC.
How about chec
he buildfarm thinks about the attached?
>
> +1
I have added it to the July commitfest.
Yours,
Laurenz Albe
ost people that come from
> programming languages without that distinction, but maybe someone
> knows some Oracle-foo that I don't?
The question already has been decided on the (better) basis of
the SQL standard, but for what it is worth:
Oracle has functions and procedures in the same name space.
Yours,
Laurenz Albe
working fine, except that your terminal does not expect unicode
and displays each character as three bytes.
What do you get if you run
SELECT name::bytea FROM person;
Yours,
Laurenz Albe
that everything that is a psql command starts with a backslash.
It might reach out to newcomers, but it will confuse people who know psql.
And frankly, anybody who has used sqlplus is used to suffering anyway.
Yours,
Laurenz Albe
ntation.
Finally, I don't see any clear statement as to the error guarantees
that the neural network prediction can give, and if it is possible that
it may degrade to scanning relevant parts of the table in some cases.
Yours,
Laurenz Albe
have to introduce new ASOF keyword. May be yacc experts can propose
> how to solve this conflict without introducing new keyword...
I think it would be highly desirable to have AS OF, because that's
the way the SQL standard has it.
Yours,
Laurenz Albe
> autovacuum and track_commit_timestamp parameters).
The feature would be most useful with some kind of "moving xid
horizon" that guarantees that only dead tuples whose xmax lies
more than a certain time interval in the past can be vacuumed.
Yours,
Laurenz Albe
nsistency, attached patch divides the Options section of oid2name
> into two sections, Options and Connection options.
I don't think it is super important, but +1 for consistency.
Yours,
Laurenz Albe
Noah Misch wrote:
> On Wed, Jun 27, 2018 at 12:09:24PM +0200, Laurenz Albe wrote:
> > Michael Paquier wrote:
> > > > I have added it to the July commitfest.
> > >
> > > Have you looked at the possibility of removing the log file constraints
> > >
On Wed, 2018-09-12 at 14:43 +0900, Michael Paquier wrote:
> On Mon, Sep 10, 2018 at 04:46:40PM +0200, Laurenz Albe wrote:
> > I didn't get pg_upgrade to work without the log file hacks; I suspect
> > that there is more than just log file locking going on, but my Windows
&g
Michael Paquier wrote:
> On Mon, Sep 10, 2018 at 04:46:40PM +0200, Laurenz Albe wrote:
> > I didn't get pg_upgrade to work without the log file hacks; I suspect
> > that there is more than just log file locking going on, but my Windows
> > skills are limited.
> >
Michael Paquier wrote:
> On Thu, Sep 13, 2018 at 03:55:20PM +0200, Laurenz Albe wrote:
> > Attached is the new, improved version of the patch.
>
> Thanks, finally pushed. I have made sure that recovery TAP tests,
> upgrade tests and bin/ tests are working properly.
Thanks fo
e are caused by frontend code suddenly defaulting
to binary mode when it was text mode before.
Would it be an option to have pgwin32_open default to text mode in
frontend code and to binary mode in backend code?
Yours,
Laurenz Albe
Tom Lane wrote:
> Laurenz Albe writes:
> > Would it be an option to have pgwin32_open default to text mode in
> > frontend code and to binary mode in backend code?
>
> Well, the question is why Michael's latest proposed patch doesn't
> accomplish that.
I was
Michael Paquier wrote:
> Thanks, I have pushed the solution from Laurenz to maintain pure
> compatibility.
Thanks for all the work!
Yours,
Laurenz Albe
Providing SQL access for administrative tasks seems to be a
good thing, see ALTER SYSTEM and pg_reload_conf().
In that vein, I propose a function pg_promote() to promote
physical standby servers.
If there are no fundamental objections, I'll add it to the
next commitfest.
Yours,
Laurenz
CT_TYPE),
errmsg("foreign key cannot be defined on ONLY \"%s\" for a
partitioned table",
Relatio
nGetRelationName(rel;
Yours,
Laurenz Albe
_logdir" and "pg_ls_waldir",
and I can imagine new requests, e.g. pg_ls_datafiles() to list the
data files in a database directory.
It may make sense to have a generic function like
pg_ls_dir(dirname text, tablespace oid)
instead. But maybe that's taking it too far...
I'll set the patch to "waiting for author".
Yours,
Laurenz Albe
; act on pg_default.
I looked at that, and I don't think you can add a DEFAULT for
system functions installed during bootstrap.
At least I failed in the attempt.
Yours,
Laurenz Albe
allback_promote? My gut tells me no, and that we ought to drop
> this option at some point in the future, still that's worth mentioning.
>
> You may want to move PROMOTE_SIGNAL_FILE in a position where xlogfuncs.c
> could use it.
Good, idea; updated
default to the pg_default tablespace.
> >
> > That would be pretty bletcherous, so +1 for just making two C functions.
>
> Alright, here's an updated patch.
Looks, good; marking as "ready for committer".
Yours,
Laurenz Albe
> [1]
> https://www.postgresql.org/message-id/CA%2BTgmoZRwy8202vxbUPBeZd_Tx5NYVtmpvBnJnOzZS3b81cpkg%40mail.gmail.com
You cannot disable a foreign scan...
Or do you want to see "disabled" if the remote query uses a disabled node?
I think that would be out of scope...
Yours,
Laurenz Albe
tty happy with it and will likely push it on New
> > > Zealand Friday (aka later today).
> >
> > I think you missed some previous output and we should fix that.
>
> Thanks. I should install ICU...
>
> I've now pushed this change and will look at the docs now.
Thanks you for taking care of that!
Yours,
Laurenz Albe
they support "crypt" and "password", and now that
PostgreSQL has removed "crypt", the users are stuck with "password"...
Actually, that may be a good reason to deprecate "password", because
then the vendor might get motivated to remedy that malady. On the other
hand, you can expect some protest...
Yours,
Laurenz Albe
change as such. But I had to focus on
the one fly in the ointment; you know how it is...
Yours,
Laurenz Albe
ollection procedure, such as Append,
> MergeAppend, Gather, etc. And I agree with you that we should
> information about it. I also think it’s worth adding additional
> information that this option does not appear in the postgres_fdw
> extension.
I cannot quite follow that either...
Yours,
Laurenz Albe
ed plan node. As a consequence, it is possible that the
planner chooses a plan using a node that has been disabled. When this
happens, the EXPLAIN output will indicate this fact.
Yours,
Laurenz Albe
On Fri, 2024-10-18 at 11:32 +0200, Pavel Stehule wrote:
> pá 18. 10. 2024 v 10:20 odesílatel Laurenz Albe
> napsal:
> > On Fri, 2024-10-18 at 07:47 +0200, Pavel Stehule wrote:
> > > Without deeper checks I don't like using GetUserNameFromId for checking
&g
On Sat, 2024-10-19 at 06:17 +0200, Pavel Stehule wrote:
> Maybe we should document so the trigger is executed with the identity used by
> DML command always,
> when the trigger function has no SECURITY DEFINER flag?
Good idea. Version 3 has documentation.
Yours,
Laurenz
y between persisted objects. Do you think that I should add a sentence
like that to the comment?
Yours,
Laurenz Albe
On Mon, 2024-10-07 at 20:11 -0400, Bruce Momjian wrote:
> On Tue, Oct 1, 2024 at 04:36:09PM +0200, Laurenz Albe wrote:
> > I think that the removal of the "adminpack" extension should
> > be listed in the section "migration to v17" as an incompatibility.
>
ff;
EXPLAIN (COSTS OFF) SELECT * FROM tab_a JOIN tab_b USING (id);
QUERY PLAN
════
Hash Join
Hash Cond: (tab_a.id = tab_b.id)
-> Seq Scan on tab_a
-> Hash
-> Seq Scan on tab_b
No disabled node shown... Ok, I still don't get it.
Yours,
Laurenz Albe
seqscan = off;
+
+EXPLAIN SELECT * FROM dummy;
+
+QUERY PLAN
+--
+ Seq Scan on dummy (cost=0.00..23.60 rows=1360 width=32)
+ Disabled: true
+
+
+
+
subplan
Yours,
Laurenz Albe
m/p/7456653e-9716-4e91-ad09-83737784c665
I believe that the speed improvement is significant, but who writes a
query like
... WHERE col IN (VALUES (1), (2), (3))
when they could write the much shorter
... WHERE col IN (1, 2, 3)
which is already converted to "= ANY"?
I wonder if it is worth the extra planning time to detect and improve
such queries.
Yours,
Laurenz Albe
different type since.
I am attaching just patch number 3 and leave you to adapt the patch set,
but I don't think any of the other patches should be affected.
Yours,
Laurenz Albe
From 422d0b6793b88951cd24a56ab45f5d7699e70c6b Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 23 Oct 2024
On Tue, 2024-10-22 at 10:41 -0700, Jeff Davis wrote:
> I attached a patch that creates partitioned tables with relpages=-1,
> and updates the docs.
Does this need any changes for pg_upgrade?
Yours,
Laurenz Albe
to read the table data, so the Seq Scan
> +is the only option available to the query planner.
> +
> +
Can we have "sequential scan" instead of "Seq Scan"?
It's somewhat unrelated, but I cannot count how many people I have talked
to who think that it is a "sequence scan".
Yours,
Laurenz Albe
n't think it is absolutely
> necessary. I see some possible changes:
>
> 1. no change
> 2. remove typid column
> 3. show typid only when variable is valid, and using regtype as output type,
> remove typname
>
> What do you prefer?
I'd say leave it as it is. I agree that it is not dangerous, and if it is
intentional that
non-existing type IDs might be displayed, I have no problem with it.
Yours,
Laurenz Albe
On Thu, 2024-10-24 at 08:03 -0700, Jeff Davis wrote:
> On Thu, 2024-10-24 at 05:01 +0300, Laurenz Albe wrote:
> > What you write above indicates that "relpages" = 0 and "reltuples" >
> > 0
> > would also be acceptable.
>
> As Tom pointed
On Wed, 2024-10-23 at 10:05 -0700, Jeff Davis wrote:
> On Wed, 2024-10-23 at 04:47 +0200, Laurenz Albe wrote:
> > On Tue, 2024-10-22 at 10:41 -0700, Jeff Davis wrote:
> > > I attached a patch that creates partitioned tables with relpages=-
> > > 1,
> > > and
an node type. This
> is by design so that the planner still maintains the ability to form a
> plan for a given query. When the resulting plan contains a disabled node,
> the EXPLAIN output will indicate this fact.
That patch is good in my opinion.
Yours,
Laurenz Albe
regards, tom lane
>
> [1] http://cfbot.cputube.org/highlights/all.html#4888
Thanks for the hint, the attached v4 patch fixes that problem.
Yours,
Laurenz Albe
From cd1f58b49dc9d004acebeabf0622b9750c598397 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 4 Nov 2024 18:24:19 +0100
Sub
On Sat, 2024-11-02 at 08:36 +0100, Pavel Stehule wrote:
> so 2. 11. 2024 v 6:46 odesílatel Laurenz Albe
> napsal:
> > - The commit message is headed "memory cleaning after DROP VARIABLE", but
> > the rest of the commit message speaks of sinval messages. These two
variables are accessed.
Calling remove_invalid_session_variables() during each COMMIT will affect
all transactions, and I don't see the benefit.
Also, do we need to call it during pg_session_variables()?
Yours,
Laurenz Albe
ipt. I would love to contribute to your organization,
> but could
> you please tell me how to get started ?
You could read
https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F
Patch review is a great way to get started.
Yours,
Laurenz Albe
my experiences in the field, I consider this need to rebuild indexes
one of the greatest current problems for the usability of PostgreSQL.
I dare say that most people would prefer living with an outdated Unicode
version.
Yours,
Laurenz Albe
On Fri, 2024-09-27 at 10:07 -0400, Greg Sabino Mullane wrote:
> So I'll be brave and throw a number out there: 1.2.
+1
Laurenz Albe
Disabled Nodes: 1
-> Hash
-> Index Scan
Disabled Nodes: 1
-> Index Scan
Disabled Nodes: 1
I have no idea how #2 could be implemented, but it would be nice to have.
Please, please, can we show the "disabled nodes" only with VERBOSE?
Yours,
Laurenz Albe
On Mon, 2024-05-06 at 16:46 +0200, Laurenz Albe wrote:
> Currently, it is pretty easy to subvert the restrictions imposed
> by row-level security and security_barrier views. All you have to
> to is use EXPLAIN (ANALYZE) and see how many rows were filtered
> out by the RLS policy
ecause there are a lot of great features in PG17 that add up to a very
> special release.
>
> Feedback welcome.
I would have added the platform-independent binary collation provider.
And perhaps "pg_createsubscriber": that can be a game-changer for setting
up logical replication.
Yours,
Laurenz Albe
client-side connection option, +
> linkend="libpq-connect-sslnegotiation">sslnegotiation=direct,
> + that allows direct TLS handshakes that avoids a round-trip negotation.
> +
> +
It should be "that avoid". Plural.
Yours,
Laurenz Albe
On Sat, 2024-09-28 at 00:04 +1200, David Rowley wrote:
> On Fri, 27 Sept 2024 at 20:42, Laurenz Albe wrote:
> > 2. The "disabled nodes" are not only shown at the nodes where nodes
> >were actually disabled, but also at every nodes above these nodes.
>
> I'
I think that the removal of the "adminpack" extension should
be listed in the section "migration to v17" as an incompatibility.
I have seen one complaint that pg_upgrade fails if the extension
is installed, but a dump/restore would also throw an error.
Your
On Tue, 2024-09-17 at 08:00 +0200, Laurenz Albe wrote:
> Using a trigram index with an non-deterministic collation can
> lead to wrong query results:
> [...]
>
> I don't know what the correct fix would be. Perhaps just refusing to use
> the index for equality comparisons
On Wed, 2024-10-02 at 21:55 +1300, David Rowley wrote:
> On Tue, 1 Oct 2024 at 06:17, Laurenz Albe wrote:
> > Why did you change "Disabled" from an integer to a boolean?
>
> I just don't think "Disabled Nodes" is all that self-documenting and
> I&
On Wed, 2024-10-02 at 10:08 -0400, Robert Haas wrote:
> On Fri, Sep 27, 2024 at 4:42 AM Laurenz Albe wrote:
> > 1. The "disabled nodes" are always displayed.
> > I'd be happier if it were only shown for COSTS ON, but I think it
> > would be best if
way of handling disabled plan nodes, I only
complained about the verbosity of the EXPLAIN output.
I don't want to see disabled nodes propagated all the way up the tree,
and I would like the output suppressed by default.
Yours,
Laurenz Albe
On Wed, 2024-10-02 at 16:48 +0800, wenhui qiu wrote:
> Whenever I check the checkpoint information in a log, most dirty pages are
> written by the checkpoint process
That's exactly how it should be!
Yours,
Laurenz Albe
hat were not actually disabled.
Perhaps a line of documentation on the EXPLAIN reference page or on the
"Using EXPLAIN" page would be in order.
Yours,
Laurenz Albe
ion variable var1
-CONTEXT: SQL expression "$1 + var1"
+CONTEXT: PL/pgSQL expression "$1 + var1"
That looks like bit rot from your commit 4af123ad45.
Yours,
Laurenz Albe
From 027fb062ecc0840bc5c2d135ebbc8ddc6b046f96 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: T
[...]
>
> So I think we ought to apply the attached as far back as we have
> nondeterministic collations.
+1
This also reminded me of [1], where I cannot think of a good fix.
Yours,
Laurenz Albe
[1]:
https://postgr.es/m/8ef4899c4acfebca45cc6c042a6dc611d25ffab1.camel%40cybertec.at
It cannot be
> given as part of the connection string like
>
> psql "service=$MY_SERVICE servicefile=MY_SERVICE_FILE"
>
> The attached patch allows that.
+1 for the idea (I didn't test the patch).
Yours,
Laurenz Albe
On Tue, 2024-11-19 at 13:42 -0800, Jeff Davis wrote:
> On Tue, 2024-11-12 at 10:40 +0100, Laurenz Albe wrote:
> > I want to reiterate what I said in the above thread:
> > If that means that indexes on strings using the "builtin" collation
> > provider need to be r
ullane, and David Fetter (from
> > 2020) [1].
>
> Add me to the pro list, please.
>
> https://www.postgresql.org/message-id/b3197ba8-225f-f53c-326d-5b1756c77...@postgresfriends.org
Me, too!
https://postgr.es/m/790e175d16cca11244907d3366a6fa376c33e882.ca...@cybertec.at
Yours,
Laurenz Albe
I'll set this patch to "ready for committer".
This is about the color of the bikeshed, and several people
have voiced their opinion. I don't think much more review
is needed. All that is needed is a committer who either
commits or rejects it.
Yours,
Laurenz Albe
t;ANALYZE (option, ...) ..." or
"CREATE FOREIGN TABLE ... OPTIONS (...)".
I think that there is less potential for confusion with "extension".
To me, a "protocol extension" would be something that adds new
features to a protocol, while a "protocol option" sounds like a
switch that has always been there.
Yours,
Laurenz Albe
[1]:
https://www.postgresql.org/docs/17/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-STARTUPMESSAGE
reloption, so that
this can be configured per table? I am not sure if a global switch is
necessary, but I am
not fundamentally against it.
Yours,
Laurenz Albe
ther down?
But I like the idea of a parameter that determines the collation.
I am aware that it is anathema here to have a GUC that influences
query semantics, but it wouldn't be any worse than creating a
database with a different collation, so I think it would be fine.
FWIW, Oracle has a
r who thinks it worth the effort or not.
Yours,
Laurenz Albe
From 55c0ed8c09b8bd83ced894a349c01f84b7c47e82 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 22 Jan 2025 13:15:27 +0100
Subject: [PATCH v4] Extend ALTER DEFAULT PRIVILEGES for large objects
Previously, ALTER DEFAULT PRIVILEGE didn&#x
On Wed, 2025-01-22 at 13:25 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > [ v4-0001-Make-AFTER-triggers-run-with-the-correct-user.patch ]
>
> I started to look at this and got distracted by wondering why
> afterTriggerAddEvent's scanning loop wasn't checking ats
f indexes though so maybe just nuance the sentence
> a
> bit.
Sorry about the 0.9.
Perhaps the wording could be more careful: ... this should be around 90 for
most newly built indexes of non-neglectable size.
Yours,
Laurenz Albe
On Thu, 2025-01-23 at 12:30 -0500, Tom Lane wrote:
> Pushed with some cosmetic adjustments
Thank you!
Yours,
Laurenz Albe
avoid "bloat", since it is jargon that
not everybody might be familiar with. I also didn't start a new
paragraph and kept it together with the explanation for index_size.
Yours,
Laurenz Albe
From 9b93682e5e7b882c78130abb2280e655e0ead360 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
D
patch, which opens the suggestion that even people who want the
> patch are seeing parts of the patch that are too much. I have seen this
> patch circling around, and I think it needs a step a back for analysis.
I'd say that patches 1 to 6 from the patch set are essential.
Yours,
Laurenz Albe
ferent databases
typically have different applications, which have different needs.
Eventually, the patch should have documentation and regression tests.
Yours,
Laurenz Albe
On Mon, 2025-01-27 at 10:13 +0100, Benoit Lobréau wrote:
> On 1/25/25 7:07 PM, Laurenz Albe wrote:
> > Looks good to me. I have one question left: the explanation for the
> > performance
> > penalty of a high leaf fragmentation sounds like it would only be relevant
&g
ect, perhaps it would
be
worth mentioning.
Yours,
Laurenz Albe
_extensions")));
I don't see the point of breaking out the role name from the message.
We don't do that in other places.
Besides, I think that the mention of the superuser should be retained.
Moreover, I think that commit 8d9978a717 pretty much established that we
should not quote names if they contain underscores.
Perhaps:
errhint("Must be superuser or member of pg_manage_extensions to create this
extension.")));
Yours,
Laurenz Albe
ted too, or at least relevant parts of it.
It addresses the perennial problem of people putting state into placeholder
GUCs to pass information between the application and the database
(SET myapp.application_id = 'user_laurenz').
Also, it cann pass information between the code in DO statements and
the surrounding SQL code.
Yours,
Laurenz Albe
n these times of hosted database services, when accessing
the log file might be difficult.
I would probably have called the function pg_uptime(), yet maybe that
is too Unix-centric.
Would it make sense to add that information to the output of
"pg_ctl status" as well? Perhaps as a new o
more than
necessary.
About when to make that change: having fewer backward-incompatible behavior
changes is desirable, which would speak for doing it now. If you feel that the
short time frame is long enough for you to write good, reliable code, great.
If you feel that it would be better for the
On Fri, 2025-03-14 at 06:58 +0100, Laurenz Albe wrote:
> On Tue, 2025-03-11 at 10:46 +0100, Laurenz Albe wrote:
> > Attached is the fifth version of the patch.
>
> ... and here, for good measure, a pgindented version
> Apart from that, no changes.
... and here is v7, improve
Yours,
Laurenz Albe
s
little point in arguing at all.
> People who aren't doing the work
> to improve the infrastructure don't get to hold the longstanding
> process hostage.
Actually, I am arguing for *not* doing the work...
Yours,
Laurenz Albe
g works:
make CFLAGS='-Wl,-rpath,\$$ORIGIN'
... at least when I run it on the shell. Putting it into an RPM spec file
might require more escaping, no idea.
Yours,
Laurenz Albe
On Tue, 2025-03-11 at 10:46 +0100, Laurenz Albe wrote:
> Attached is the fifth version of the patch.
... and here, for good measure, a pgindented version
Apart from that, no changes.
Yours,
Laurenz Albe
From d644d3fe1b2c5ab2cbf7f10e9c653b7baa9efe01 Mon Sep 17 00:00:00 2001
From: Laurenz A
5RZ0uNofEXfEfNw3uRN3D3oXkFPQ_s%2BhuLLHMKR_%2BMCk8RPQ%40mail.gmail.com#c357c56c3924642e8ef73cc1c8a0286e
>
> Two points were made:
>
> 1) this should be on by default
> 2) there should be no GUC for it.
+1 on both
Yours,
Laurenz Albe
e too.
> From my perspective, the whole point of the builtin collation was to
> one option that avoids these problems that come with updating both ICU
> and glibc.
+1
Yours,
Laurenz Albe
On Sat, 2025-03-15 at 13:09 +0100, Christoph Berg wrote:
> Do we care about any of these?
>
> AIX
We dropped support for it, but there are efforts to change that.
Yours,
Laurenz Albe
ould surprise
and confuse many users.
This is not the only way a user can do damage to the system by overriding the
administrator's settings. Users can override all autovacuum settings and even
disable autovacuum on a table. I don't think these settings are less dangerous
than VACUUM truncation.
Yours,
Laurenz Albe
701 - 800 of 852 matches
Mail list logo
