.
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
change as such. But I had to focus on
the one fly in the ointment; you know how it is...
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
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
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
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
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
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
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 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
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 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'
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
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
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
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 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
e that the operator ignores the collation, so
the result is correct. With equality, there is no such loophole.
I don't know what the correct fix would be. Perhaps just refusing to use
the index for equality comparisons with non-deterministic collations.
Yours,
Laurenz Albe
nd
> hasn't noticed a problem because they never change their
> timezone setting, they might not appreciate us breaking it.
I hope that there are few cases of that in the field, and I think it
is OK to break them. After all, it can be fixed with a simple
ALTER TABLE foo ALTER id TYPE timestamptz;
If the session time zone is UTC, that wouldn't even require a rewrite.
I agree that it cannot be backpatched.
Yours,
Laurenz Albe
On Wed, 2024-03-06 at 14:32 +0100, Laurenz Albe wrote:
> On Mon, 2023-11-06 at 18:29 +0100, Tomas Vondra wrote:
> > On 11/6/23 14:23, Laurenz Albe wrote:
> > > This behavior looks buggy to me. What do you think?
> > > I cannot imagine that it is a security problem, thou
tested, failed
>
> LGTM
>
> The new status of this patch is: Ready for Committer
Huh? Do you mean "tested, passes"?
Yours,
Laurenz Albe
-> * be false, due possible accepting invalidation message inside domain
> <--> * check. But now, the variable, and all dependencies are locked, so we
> <--> * don't need to repeat validation.
> <--> */
Much better.
Here is an improved version:
Although "svar" is freshly validated in this point, svar->is_valid can
be false, if an invalidation message ws processed during the domain check.
But the variable and all its dependencies are locked now, so we don't need
to repeat the validation.
Yours,
Laurenz Albe
iticism, and I think the way you split up the patch set right
now
is as good as it probably gets. Ideally, one could say something like "we need
at least
patch 1 to 4, 5 and 6 are optional, but desirable, all others can easily be
deferred
to a later time".
Yours,
Laurenz Albe
On Thu, 2024-08-15 at 07:55 +0200, Pavel Stehule wrote:
> út 30. 7. 2024 v 21:46 odesílatel Laurenz Albe
> napsal:
> > - A general reminder: single line comments should start with a lower case
> > letter and have to period in the end:
>
> Should it be "have not to
tmt(date) AS SELECT $1;
> EXECUTE stmt(var);
> ERROR: paramid of PARAM_VARIABLE param is out of range
Or does a later patch take care of that?
Yours,
Laurenz Albe
clients. We should give them that choice.
I think that you are right.
But what do you tell the users who would not accept that risk?
Yours,
Laurenz Albe
e tables on this side
> of the documentation should look alike.
There are only four hypothetical-set aggregate functions, so it is no problem
to find a function in that list.
I would say that it makes sense to apply the proposed patch, even if we
don't sort that short list.
Yours,
Laurenz Albe
On Wed, 2024-07-31 at 08:41 +0200, Pavel Stehule wrote:
> Probably you didn't attach new files - the second patch is not complete. Or
> you didn't make changes there?
Hm. What is missing?
Yours,
Laurenz Albe
On Thu, 2024-07-25 at 16:12 -0400, Robert Haas wrote:
> On Thu, Jul 25, 2024 at 8:51 AM Laurenz Albe wrote:
> > The attached patch uses your wording for the first sentence.
> >
> > I left out the last sentence from your suggestion, because it sounded
> > like it is l
detail("error codes can only contain digits and ASCII letters.");
> goto failed;
> }
> and we can do this in the beginning after the len check.
isalnum() operates on a single character and depends on the current locale.
See my comments to 3. above.
Please let me know what you think, particularly about the locale problem.
Yours,
Laurenz Albe
1 - 100 of 818 matches
Mail list logo
