to
> the respective authors. Let’s wait a bit and see if they show
> interest.
Thank you for doing that!
Yours,
Laurenz Albe
On Thu, 2025-07-24 at 18:58 +0200, Álvaro Herrera wrote:
> On 2025-Jul-24, Laurenz Albe wrote:
>
> > I just happened to look into https://commitfest.postgresql.org/52/
> > and saw plenty of "Active patches" there.
>
> I *think* we should close the Waiti
"? Or some new state "Abandoned"?
Yours,
Laurenz Albe
[1]: https://postgr.es/m/003e3a66-8fcc-4ca0-9e0e-c0afda1c9424%40eisentraut.org
On Thu, 2025-07-17 at 11:59 -0700, Jeff Davis wrote:
> On Thu, 2025-07-17 at 08:30 +0200, Laurenz Albe wrote:
> > I wasn't aware how Oracle handles case mapping, but it seems you
> > are right:
>
> How does it handle UPPER('ß')? If the result is 'ß',
On Thu, 2025-07-17 at 12:58 -0400, Tom Lane wrote:
> Cool, done that way.
Thanks!
Yours,
Laurenz Albe
have excluded the column "phone" from
the list of published columns. So it cannot be a part of the replica identity,
the set of columns used in the WHERE condition on the subscriber.
Stick with REPLICA IDENTITY DEFAULT.
Yours,
Laurenz Albe
On Wed, 2025-07-16 at 09:46 -0700, Jeff Davis wrote:
> On Wed, 2025-07-16 at 08:29 +0200, Laurenz Albe wrote:
> > I have a radical proposal: Rather than having "initdb" default to
> > whatever locale is in the environment, make it default the the
> > builtin provider
On Wed, 2025-07-16 at 15:36 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > On Thu, 2025-05-08 at 22:01 +0200, Daniele Varrazzo wrote:
> > > Please find attached a new patch that doesn't change the behaviour and
> > > just makes sure to not return NULL
g tests
for that. I wondered if it was worth adding a test, but could not
find a convenient place. Adding a TAP test seems a bit out of
proportion for a small fix like that.
Status set to "waiting on author".
Yours,
Laurenz Albe
ment, make it default the the builtin
provider and the C collation. Wherever people need a natural language
collation, they can say so explicitly.
That would do nothing for existing installations, but it would get rid
of the problem for new clusters.
Not that I want to present Oracle as an example to fo
her disable JIT by default than parallel query.
But I have no pitchfork.
Yours,
Laurenz Albe
gt;issues_sql_like(
> [
> 'vacuumdb', '--analyze-only', 'postgres'
> ],
> qr/statement:\s+ANALYZE\s+public\.parent_table/s,
> '--analyze_only updates statistics for partitioned tables');
Good idea; done in the attached versio
s just the average.
> We see from these test cases that there are frequently
> a few outliers that are far from the average. I'm tempted
> to rephrase as
>
> Average loop time including overhead: 731.26 ns
>
> or some variant of that. Thoughts?
I think that is a good idea.
Yours,
Laurenz Albe
I disagree here. There are regular ON TRUNCATE triggers on tables, so I don't
see the need. You can define a trigger with the same trigger function on
several tables.
Yours,
Laurenz Albe
nsidered to prevent
> such failures:
>
> 1. Restrict the creation of user objects within the `pg_catalog` schema.
That's already the case:
test=# CREATE TABLE pg_catalog.new ();
ERROR: permission denied to create "pg_catalog.new"
DETAIL: System catalog modifications are currently disallowed.
Yours,
Laurenz Albe
t; > --no-statistics, --with-data, and --with-schema at this point.
> >
> > That's OK with me.
>
> Same.
I must be missing something, but I think --no-statistics is sorely needed.
How else can I get the effect of
pg_dump --no-statistics mydb
Yours,
Laurenz Albe
option will also
+ flush UNLOGGED relations; the default is off.
+
+
+
How about:
FLUSH_UNLOGGED
Normally, data files marked as UNLOGGED are not
flushed to disk during a checkpoint. Enabling this option will also
flush UNLOGGED relations. This option is disabled
by default.
Yours,
Laurenz Albe
gt; change. This could look like:
> Suggested Fields:
> • previous_value: The value of the parameter before the change
> • changed_by: The user who made the change
> • change_time: Timestamp of the change
> Benefits:
> • Provides a detailed audit trail of configuration changes
> • Helps with troubleshooting issues caused by parameter modifications
> • Enhances accountability in cloud-managed environments
That would always be incomplete, since you can manually edit "postgresql.conf".
And audit information that is incomplete tends to be useless.
Most cloud providers provide special interfaces to change parameters. These
could
easily track these changes, so I see little need to try and do that in core.
Yours,
Laurenz Albe
rade. I'm tempted to suggest that we apply this to v18, but I'm
> > content to leave it for v19 if nobody feels too strongly about it.
>
> That seems like a reasonable thing to do for v18 to me.
+1
Laurenz Albe
tensions that I am aware of.
In addition to the link you mention, you can search Github and
pgxn.org; that should cover a lot of them.
Yours,
Laurenz Albe
The obvious question is how many people would suffer because
of that removal, as it would prevent them from using pg_upgrade.
Can anybody who works in a region that uses these encodings make
an educated guess?
Yours,
Laurenz Albe
about schema
> owner privileges not being included in the output of pg_dump – do you
> think it would be better to send a separate email to suggest adding an
> explanation for this to the documentation?
I think that is unnecessary. "pg_dump" doesn't need to preserve
everyth
ivileges always include all privileges for the owner,
and can include some privileges for PUBLIC depending on the
object type, as explained above.
Yours,
Laurenz Albe
On Tue, 2025-05-20 at 16:58 -0400, Scott Mead wrote:
> On Wed, May 14, 2025, at 4:06 AM, Laurenz Albe wrote:
> > On Tue, 2025-05-13 at 17:53 -0400, Scott Mead wrote:
> > > On Tue, May 13, 2025, at 5:07 PM, Greg Sabino Mullane wrote:
> > > > On Tue, May 13, 202
n is not nice, but at least
it would make it easier for Pavel to move on and spend his energy elsewhere.
Yours,
Laurenz Albe
down version, but I don't see the patch moving in that
> direction.
>
> Now, of course, if I am the only one who feels this way, I can suppress
> these emails on my end.
In my opinion, this patch set is adding something that would be valuable to
have in core.
If no committer intends to pick it up and commit it, I think the proper
action would be to step up and reject the patch set, not complain about the
insistence of the author.
Yours,
Laurenz Albe
see many cases where parallel query works just like it should
and leads to a better user experience.
I have come to disable JIT by default, but not parallel query.
The primary problem that I encounter with parallel query is that dynamic
shared memory segments grow to a size where they cause OOM errors.
That's the most frequent reason for me to recommend disabling parallel query.
Yours,
Laurenz Albe
On the other hand, the catalogs are described in the documentation, which
gives them more exposure, and it doesn't seem unreasonable to document
breaking changes as well.
Do you have an idea how many changes there are? If there are not too many,
and somebody is willing to do the work, I wouldn't be against it.
Yours,
Laurenz Albe
ows Aurora internals happens to read your question, you won't
get a good answer.
You could check if your I/O quota are exceeded...
Yours,
Laurenz Albe
every table. In my opinion,
> this is fine.
I don't think that is fine. I think it would make the feature unusable for
most cases.
At the very least, there would have to be a way to specify which tables are
affected.
Yours,
Laurenz Albe
.
https://postgr.es/m/CACLU5mThm-uCtERMVHMoGED2EPfyS54j83WB20s_BmzVQuMkpg%40mail.gmail.com
Seems like Kirk didn't pursue this further.
Yours,
Laurenz Albe
t; how to make their lives less painful in the future. Right now
> I think we're guessing --- I certainly am. Maybe some of the people
> on this thread have access to such details, but they aren't sharing.
So - should this patch be rejected or moved to the next CF in the hope
to attract some review from said hosting providers?
Michael, do you know any hosting providers you can prompt to comment?
Yours,
Laurenz Albe
On Fri, 2024-07-19 at 11:54 +0200, Laurenz Albe wrote:
> On Thu, 2024-07-18 at 12:25 +0200, Michael Banck wrote:
> > this patch is still on the table, though for v18 now.
> >
> > Nathan mentioned up-thread that he was hesitant to commit this without
> > further discuss
t what sort of filtering is needed to be appropriate
> within elog.c itself.
>
> Also, just as a minor coding thought, I'd suggest using -1 not 0
> to terminate the array of encoded SQLSTATEs, rather than assuming
> that nobody would write 0. Compare commit 58fdca220.
I agree with these assessments and will withdraw the patch.
Yours,
Laurenz Albe
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
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
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
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
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 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
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
s as expected.
The code looks good to me.
Yours,
Laurenz Albe
thing submitted to the mailing list is no longer private
intellectual property. You are free and welcome to start working
on any patch that you are interested in and that seems neglected
by the author. There is no problem with listing more than one
author.
Yours,
Laurenz Albe
encodeable in UTF-8? At this point
> I'm pretty sure Unicode has subsumed essentially every character ever
> mentioned
> in a standards document.
There is a difference between "encodable" and "encoded". You'd have to figure
out the actual encoding of the database name and convert that to UTF-8.
Yours,
Laurenz Albe
_errcodesto an empty string
> and then set it back to comma separated values
These two points were actually caused by a memory management bug that I
had inadvertently introduced in the assign hook. They should be fixed now.
Attached is the fifth version of the patch.
Yours,
Laurenz Albe
Fro
d of doing this?
That's quite true. Perhaps the patch should be rejected after all.
Yours,
Laurenz Albe
vailable.
We could shove a test into a regression test for an existing contrib,
but that would be somewhat off-topic there. Not sure what would be best.
Yours,
Laurenz Albe
th
"durability" instead. I removed the link to the reliability discussion
and rephrased the sentence somewhat.
+
+
+ If specified on a partitioned table the property is recorded but ignored:
+ the entire partitioned table is not automatically truncated after a crash
+
stashed it into the autovacuum
> one. Bikeshedding welcome.
Why not use "Client Connection Defaults / Statement Behavior", just like for
"vacuum_freeze_min_age"? I don't think that "autovacuum" is appropriate,
since it applies to manual VACUUM as well.
Yours,
Laurenz Albe
On Wed, 2025-02-26 at 22:11 -0500, Andy Alsup wrote:
> Please find the latest patch files attached.
This is good to go. If you add it to the commitfest, I'm happy to
mark it "ready for committer".
Yours,
Laurenz Albe
(subq)
That is true, but I don't see how it leads to an anti-join
without further consideration. Perhaps you mean something
else by "pull up"...
Yours,
Laurenz Albe
uid can be used
to store any UUID, regardless of the origin and the UUID version.
I would be happy if you added something like that again.
Yours,
Laurenz Albe
On Mon, 2025-02-24 at 17:12 +0800, wenhui qiu wrote:
> Do we have plans for NOT IN subquery pull up?
As mentioned before, that is not possible.
Best practice is to avoid NOT IN with subqueries altogether.
The result is usually not what people expect it to be.
Yours,
Laurenz Albe
--
*E-M
that sentence could be
The PostgreSQL data type uuid supports all kinds of UUIDs,
regardless of their version.
We don't mention that "integer" can be used to store integers generated
inside and outside PostgreSQL, so I don't think we need to mention that
here.
About the
REINDEX did
not fix the bad query result, but update to 17.3 did.
Yours,
Laurenz Albe
--
*E-Mail Disclaimer*
Der Inhalt dieser E-Mail ist ausschliesslich fuer den
bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat
dieser E-Mail oder dessen Vertreter sein sollten, so beac
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
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
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
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
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
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
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
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
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
_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
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
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
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
[...]
>
> 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
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
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
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
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
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
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
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
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
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
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
y between persisted objects. Do you think that I should add a sentence
like that to the comment?
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
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
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
> [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
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.
>
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
1 - 100 of 848 matches
Mail list logo
