luster, so having a locale-agnostic collation is often better than
inheriting whatever default happened to be set in your shell.
For example, the Debian/Ubuntu binary packages create a cluster when
you install the server package, and most people just go on using that.
Yours,
Laurenz Albe
r code. It is not FDW specific, since I discovered it with
oracle_fdw and could reproduce it with postgres_fdw.
I was aware that it is awkward to add a test to a contrib module, but
I thought that I should add a test that exercises the new code path.
But I am fine without the postgres_fdw test.
Yours,
Laurenz Albe
And here is v10, which includes tab completion for the new option.
Yours,
Laurenz Albe
From dfe6d36d79c74fba7bf70b990fdada166d012ff4 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Thu, 23 Mar 2023 19:28:49 +0100
Subject: [PATCH] Add EXPLAIN option GENERIC_PLAN
This allows EXPLAIN to generate
2=$1
I did that, with a different comment.
> The test involving postgres_fdw is still necessary to exercise the new
> EXEC_FLAG_EXPLAIN_GENERIC code path, but needs to be moved elsewhere,
> probably src/test/modules/.
Tests for postgres_fdw are in contrib/postgres_fdw/sql/postgres_fdw.sql
be expected).
I checked the documentation, tested "pg_dump" support, everything fine.
I'll mark it as "ready for committer".
Yours,
Laurenz Albe
? Maybe there are people using special
> delimiters/terminators and they need them to be treated a certain way
> during comparisons?
I regularly see complaints about the sort order; recently this one:
https://postgr.es/m/cafcrh--xt-j8awoavhb216kom6tqnap35ttveqqs5bhh7gm...@mail.gmail.com
So being able to influence the sort order is useful.
Yours,
Laurenz Albe
at would be an initdb option. Is that too many initdb options
> then? It would be easy to add, if we think it's worth it.
An alternative would be to document that you can drop "template1" and
create it again using the ICU collation rules you need.
But I'd prefer an "initdb" option.
Yours,
Laurenz Albe
ate`.
It adds some value by being simpler and uniform across all platforms.
I'll mark the patch as "ready for committer".
Yours,
Laurenz Albe
as far as I know.
Yours,
Laurenz Albe
ou should configure your
package manager not to upgrade the ICU library.
Yours,
Laurenz Albe
e a database
with "ICU_LOCALE x", the rules are not copied over.
I don't know if that is intended or not, but it surprises me.
Should that be a WARNING? Or, since creating a database with a collation
that does not exist in "template0" doesn't make much sense (or does it?),
is there a way to forbid that?
Yours,
Laurenz Albe
On Mon, 2023-02-13 at 16:33 -0800, Andres Freund wrote:
> On 2023-02-05 18:24:03 +0100, Laurenz Albe wrote:
> > Anyway, attached is v7 that tries to do it that way.
>
> This consistently fails on CI:
> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42
can change in the
meantime. Think of prepared statements using a generic plan.
Yours,
Laurenz Albe
avoid having to change all the places that check EXEC_FLAG_EXPLAIN_ONLY
to also check for the new flag, I decided that the new flag can only be
used as "add-on" to EXEC_FLAG_EXPLAIN_ONLY.
Yours,
Laurenz Albe
From cd0b5a1a4f301bb7fad9088d5763989f5dde4636 Mon Sep 17 00:00:00 2001
From: Lau
On Sat, 2023-02-04 at 14:41 +0100, Daniel Verite wrote:
> Laurenz Albe wrote:
>
> > Cool so far. Now I created a database with that locale:
> >
> > CREATE DATABASE teutsch LOCALE_PROVIDER icu ICU_LOCALE german_phone
> > LOCALE "de_AT.utf8" TE
On Fri, 2023-02-03 at 09:44 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > I played around with it, and I ran into a problem with partitions that
> > are foreign tables:
> > ...
> > EXPLAIN (GENERIC_PLAN) SELECT * FROM looppart WHERE key = $1;
> > ERROR
On Tue, 2023-01-31 at 13:49 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > [ 0001-Add-EXPLAIN-option-GENERIC_PLAN.v4.patch ]
>
> I took a closer look at this patch, and didn't like the implementation
> much. You're not matching the behavior of PREPARE at all: for exa
tion-root=on/off/auto", where
> auto means "not with hash partitions" or the like?
That's perhaps the best way. So users who know that their hash
partitions won't change and want the small speed benefit can have it.
Yours,
Laurenz Albe
t of this patch, however, is that "daticurules" is not
set in "pg_database". Looking at the code, that column seems to be copied
from the template database, but cannot be overridden.
Perhaps this only needs more documentation, but I am confused.
Yours,
Laurenz Albe
of pg_xact_status, so I suspect that it
is not a widely known and used feature. After reading the documentation,
I'd say that anybody who uses it will want it to give a reliable answer.
So I'd agree that it is better to make it more expensive, but live up to
its promise.
Yours,
Laurenz Albe
On Wed, 2023-01-25 at 16:26 +1300, David Rowley wrote:
> On Wed, 18 Jan 2023 at 22:15, Laurenz Albe wrote:
> > Attached is a new version of my patch that tries to improve the wording.
>
> I had a look at this and agree that we should adjust the paragraph in
> question if
On Tue, 2023-01-24 at 01:38 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > We throw an error if the expression in a CREATE INDEX statement is not
> > IMMUTABLE.
> > But while the documentation notes that expressions in CHECK constraints are
> > not
> >
catch all abuse,
but it would be better than nothing.
There is of course the worry of breaking upgrade for unsafe constraints, but is
there any other reason not to enforce immutability?
Yours,
Laurenz Albe
ore TB disk storage.
Yours,
Laurenz Albe
.com/en/streaming-replication-conflicts-in-postgresql/
Yours,
Laurenz Albe
On Thu, 2023-01-19 at 15:56 -0500, Bruce Momjian wrote:
> On Thu, Jan 19, 2023 at 01:50:05PM +0100, Laurenz Albe wrote:
> > On Wed, 2023-01-18 at 16:23 -0500, Bruce Momjian wrote:
> > > Is it possible to document when partition table statistics helps?
> >
> > I think
On Wed, 2023-01-18 at 15:03 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
> > > I seem to recall that the original idea was to report the timestamp
> > > of the commit/abort record we are stopping at. Maybe my me
On Wed, 2023-01-18 at 16:23 -0500, Bruce Momjian wrote:
> Is it possible to document when partition table statistics helps?
I think it would be difficult to come up with an exhaustive list.
Yours,
Laurenz Albe
t; > partitions changes significantly.
> >
>
> "partitions are normal tables" was techically wrong, as partitions can
> also be partitioned.
I am fine with your tweaks. I think this is good to go.
Yours,
Laurenz Albe
this thread[1]. It doesn't take
an exotic query.
Attached is a new version of my patch that tries to improve the wording.
Yours,
Laurenz Albe
[1]: https://postgr.es/m/3df5c68b-13aa-53d0-c0ec-ed98e6972e2e%40postgrespro.ru
From 53da8083556364490d42077492e608152f9ae02e Mon Sep 17 00:00:00 2001
Fr
On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-01-16 at 19:59 +0100, Torsten Förtsch wrote:
> > > So, the timestamp displayed in the log message is certainly wrong.
>
> > If recovery stops at a WAL record that has no timest
time. I think we should show the recovery stop time
only if time was the target, as in the attached patch.
Yours,
Laurenz Albe
From 622e52bbd652fc8872448e46c3ca0bc78dd847fe Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 17 Jan 2023 10:38:40 +0100
Subject: [PATCH] Don't show bogus recovery stop time
bool generic_plan;
> | ^~~~
Thanks for checking. The variable should indeed be initialized, although
my compiler didn't complain.
Attached is a fixed version.
Yours,
Laurenz Albe
From baf60d9480d8022866d1ed77b00c7b8506f97f70 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
On Tue, 2022-12-06 at 10:17 -0800, Andres Freund wrote:
> On 2022-10-29 10:35:26 +0200, Laurenz Albe wrote:
> > > > Here is a patch that
> > > > implements it with an EXPLAIN option named GENERIC_PLAN.
>
> This fails to build the docs:
>
> https://cirrus-c
On Wed, 2022-11-30 at 10:09 +0100, Vik Fearing wrote:
> On 11/29/22 17:29, Laurenz Albe wrote:
> > On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
> > > I disagree. A user does not need to know that a table is partitionned,
> > > and if the user wants a uni
y without thinking too hard about it,
only to discover later that dropping old partitions has become a problem,
I would not be too happy either.
Yours,
Laurenz Albe
this, people start
worrying about normal autovacuum runs because they occasionally experience
a table age autovacuum that is much heavier than the other ones. And
they can no longer tell the reason, because it doesn't show up anywhere.
Yours,
Laurenz Albe
offs were chosen because they're
> easy to understand and remember, which is fairly arbitrary.
The target is a table that receives no DML at all, right?
I think that is a good idea.
Wouldn't it make sense to trigger that at *half* "autovacuum_freeze_max_age"?
Yours,
Laurenz Albe
n that status.
Yours,
Laurenz Albe
be a
> difficult change to deal with, I concur that we don't need to
> deprecate it ahead of time.
Since I am the only one that seems to worry, I'll shut up. You are probably
right that it the feature won't be missed by many users.
Yours,
Laurenz Albe
s
> + will have virtualxids but NULL
> + transactionids, while read-write transactions
> + will have both as non-NULL.
> +
Perhaps the following will be prettier than "have both as non-NULL":
..., while both columns will be set in read-write transactions.
Yours,
Laurenz Albe
On Mon, 2022-11-21 at 07:36 +, Simon Riggs wrote:
> On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance for anyone who
On Mon, 2022-11-21 at 11:42 +0530, Bharath Rupireddy wrote:
> On Mon, Nov 21, 2022 at 10:37 AM Laurenz Albe
> wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance fo
, but I don't think that it is a good idea to deviate from our
usual standard of deprecating a feature for about five years before
actually removing it.
Yours,
Laurenz Albe
On Thu, 2022-11-10 at 12:17 +0100, Alvaro Herrera wrote:
> On 2022-Nov-10, Laurenz Albe wrote:
> > On Wed, 2022-11-09 at 09:16 -0500, Robert Treat wrote:
> > > > > - If AND CHAIN is specified, a new
> > > > > transaction is
> > > >
On Wed, 2022-11-09 at 09:16 -0500, Robert Treat wrote:
> On Mon, Nov 7, 2022 at 5:04 PM Laurenz Albe wrote:
> > Some comments:
> >
>
> > > --- a/doc/src/sgml/ref/release_savepoint.sgml
> > > +++ b/doc/src/sgml/ref/release_savepoint.sgml
> >
ow is that?
It is better. Did you take my suggestions from [1] into account in your
latest cumulative patch in [2]? Otherwise, it will be difficult to
integrate both.
Yours,
Laurenz Albe
[1]:
https://postgr.es/m/3603e6e85544daa5300c7106c31bc52673711cd0.camel%40cybertec.at
[2]: https://postgr.es/m/Y2nP04/3BHQOviVB%40momjian.us
On Mon, 2022-11-07 at 23:04 +0100, Laurenz Albe wrote:
> On Sat, 2022-11-05 at 10:08 +, Simon Riggs wrote:
> > Agreed; new compilation patch attached, including mine and then
> > Robert's suggested rewordings.
>
> Thanks. There is clearly a lot of usefule informati
and can be inspected using the
> +extension. Row-level read locks might also require the assignment
> +of multixact IDs (mxid). Mxids are recorded in
> +the pg_multixact directory.
"are recorded directly in *the* locked rows"
I think the mention of multixacts should link to
. Again, I would not
specifically mention the directory, since it is already described in
"storage.sgml", but I have no strong optinion there.
> +
> +
> + Subtransactions
> +The word subtransaction is often abbreviated as
> +subxact.
I'd use , not .
> +If a subtransaction is assigned a non-virtual transaction ID,
> +its transaction ID is referred to as a subxid.
Again, I would use , since we don't "subxid"
elsewhere.
+ Up to
+64 open subxids are cached in shared memory for each backend; after
+that point, the overhead increases significantly since we must look
+up subxid entries in pg_subtrans.
Comma before "since". Perhaps you should mention that this means disk I/O.
Yours,
Laurenz Albe
;autovacuum_vacuum_cost_delay". Reduce that parameter for more
autovacuum speed.
Yours,
Laurenz Albe
ch bigger. Is this just an incremental patch? If yes, it would
be nice to have a "grand total" patch, so that I can read it all
in one go.
Yours,
Laurenz Albe
ch
I am not so sure about.
I understand that you did that so that "explain_regress" can turn off BUFFERS
and there is no extra churn in the regression tests.
Still, it would be a shame if resistance against "explain_regress" would
be a show-stopper for 0003.
If I could get my way, I'd want two separate patches: first, one to turn
BUFFERS on, and second one for "explain_regress" with its current functionality
on top of that.
Yours,
Laurenz Albe
On Tue, 2022-10-25 at 19:03 +0800, Julien Rouhaud wrote:
> On Tue, Oct 25, 2022 at 11:08:27AM +0200, Laurenz Albe wrote:
> > Here is a patch that
> > implements it with an EXPLAIN option named GENERIC_PLAN.
>
> I only have a quick look at the patch for now. Any reas
details, ...
Why not add this functionality to the GUC?
0005 suppresses "rows removed by filter", but how is that machine dependent?
> BTW, I think it may be that the GUC should be marked PGDLLIMPORT ?
I think it is project policy to apply this mark wherever it is needed. Do you
think
that third-party extensions might need to use this in C code?
Yours,
Laurenz Albe
e to go to great lengths
> trying to "unjumble" such queries, so having a way to easily get the answer
> for
> a generic plan would be great.
Thanks for the suggestions and the encouragement. Here is a patch that
implements it with an EXPLAIN option named GENERIC_PLAN.
Yours,
Laurenz Albe
F
uraged.
Anybody who knows enough about PostgreSQL to be sure that what they are
doing is correct should be smart enough to know how to edit the copied file.
Yours,
Laurenz Albe
ged EXPLAIN (ANALYZE, BUFFERS),
but it can definitely be helpful.
I tied that behavior to the setting of "plan_cache_mode" where you
are guaranteed to get a generic plan; I couldn't think of a better way.
Yours,
Laurenz Albe
From 2bc91581acd478d4648176b58745cadb835d5fbc Mon Sep 17 00:00:00
ways used the statistics of the partitions.
Yours,
Laurenz Albe
From 5209f228f09e52780535edacfee5f7efd2c25081 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Wed, 5 Oct 2022 10:31:47 +0200
Subject: [PATCH] Improve autovacuum doc on partitioned tables
The documentation mentioned that autovacuum doesn'
over time, the use of the older serial
> mechanisms would go away.
I think that would be great.
That might generate some confusion among users who follow old tutorials
and are surprised that the eventual table definition differs, but I'd say
that is a good thing.
Yours,
Laurenz Albe
this is a pretty obvious case of pilot error.
Yours,
Laurenz Albe
thread?
For reference: that was
https://postgr.es/m/f6a491b32cb44bb5daaafec835364f7149348fa1.ca...@cybertec.at
Yours,
Laurenz Albe
On Tue, 2022-09-13 at 16:13 +0200, Matthias van de Meent wrote:
> On Tue, 13 Sept 2022 at 15:45, Tom Lane wrote:
> > Laurenz Albe writes:
> > > But once they are deleted or updated, even the transaction that created
> > > them cannot
> > > see them any mor
On Tue, 2022-09-13 at 11:47 +0300, Nikita Malakhov wrote:
> On Tue, Sep 13, 2022 at 11:06 AM Laurenz Albe
> wrote:
> > Shouldn't such tuples be considered dead right away, even if the inserting
> > transaction is still active? That would allow cleaning them up even before
&
and not HEAPTUPLE_DEAD?
Yours,
Laurenz Albe
On Thu, 2022-08-18 at 11:04 +0200, Alvaro Herrera wrote:
> On 2022-Aug-18, Laurenz Albe wrote:
> > On Wed, 2022-08-17 at 20:12 +0200, Alvaro Herrera wrote:
> > > Using ALTER TABLE DROP CONSTRAINT works fine, and the 'attnotnull'
> > > bit is lost when the last on
okay. But what should
> happen?
>
> 1. a CHECK(col IS NOT NULL) constraint is created for each column
> 2. a PRIMARY KEY () constraint is created
I think it would be best to create a primary key constraint on the
partition.
Yours,
Laurenz Albe
mp
2022-07-05 00:00:00+02
(1 row)
test=> SET lc_time = 'de_DE.utf8';
SET
test=> SELECT to_timestamp('2022-July-05', '-TMMonth-DD');
ERROR: invalid value "July-05" for "Month"
DETAIL: The given value did not match any of the allowed values for this field.
Yours,
Laurenz Albe
" is how that timestamp is converted to a
string, but that's a different affair.
Yours,
Laurenz Albe
On Wed, 2022-06-29 at 00:05 -0700, Andres Freund wrote:
> On 2022-06-29 08:51:10 +0200, Laurenz Albe wrote:
> > On Tue, 2022-06-28 at 16:27 -0700, Andres Freund wrote:
> > > > Experience shows that 99% of the time one can run PostgreSQL just fine
> > > > without a
uot;, which should already be warning enough.
Perhaps some stronger wording in the documetation would be beneficial.
I have little sympathy with people who set unusual parameters without
even glancing at the documentation.
Yours,
Laurenz Albe
eeded at all.
I also disagree with that. Not having a superuser is one of the pain
points with using a hosted database: no untrusted procedural languages,
no untrusted extensions (unless someone hacked up PostgreSQL or provided
a workaround akin to a SECURITY DEFINER function), etc.
Yours,
Laurenz Albe
ected behavior on account of the timing of
permission checks. Other than that, I consider this below the threshold for
user-facing documentation.
I'm ok with just doing nothing here, I just wanted it discussed in public.
Yours,
Laurenz Albe
On Thu, 2022-06-09 at 21:55 +0900, Etsuro Fujita wrote:
> On Thu, Jun 9, 2022 at 9:49 AM Laurenz Albe wrote:
> > On Wed, 2022-06-08 at 19:06 +0900, Etsuro Fujita wrote:
> > > On Wed, Jun 8, 2022 at 2:51 PM Kyotaro Horiguchi
> > > wrote:
> > > > At Wed, 0
On Wed, 2022-06-08 at 19:06 +0900, Etsuro Fujita wrote:
> On Wed, Jun 8, 2022 at 2:51 PM Kyotaro Horiguchi
> wrote:
> > At Wed, 08 Jun 2022 07:05:09 +0200, Laurenz Albe
> > wrote in
> > > diff --git a/doc/src/sgml/postgres-fdw.sgml
> > > b/doc/src/sgml/post
On Wed, 2022-06-08 at 13:06 +0900, Kyotaro Horiguchi wrote:
> At Wed, 08 Jun 2022 12:09:27 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Wed, 08 Jun 2022 04:38:02 +0200, Laurenz Albe
> > wrote in
> > > If anything, it should be done in the FDW, b
On Wed, 2022-06-08 at 11:12 +0900, Kyotaro Horiguchi wrote:
> At Tue, 07 Jun 2022 11:24:55 -0300, "Euler Taveira" wrote
> in
> > On Tue, Jun 7, 2022, at 12:03 AM, Laurenz Albe wrote:
> > > On Sat, 2022-06-04 at 21:18 +, Phil Florent wrote:
> > > &
ons
on the foreign table.
I feel that that is no bug, but I'd be curious to know if others disagree.
Yours,
Laurenz Albe
pported.
+1 on the general idea.
At least, it will makes these operations simpler, but probably also less
invasive (no need to detach the affected partitions).
I didn't read the patch, but what lock level does that place on the
partitioned table? Anything more than ACCESS SHARE?
Yours,
Laurenz Albe
rries:
1. It would be a good idea good to make sure that there is not both
"extension--%--2.0.sql" and "extension--1.0--2.0.sql" present.
Otherwise the behavior might be indeterministic.
2. What if you have a "postgis--%--3.3.sql", and somebody tries to upgrade
their PostGIS 1.1 installation with it? Would that work?
Having a lower bound for a matching version might be a good idea,
although I have no idea how to do that.
Yours,
Laurenz Albe
transactions and the effect remains
> after the transaction finished. Is it unacceptable behaviours,
> isn't it?
+1
Yours,
Laurenz Albe
4
> or
> Tuples: inserted=1 updated=2 deleted=3 skipped=4
>
> Note double spaces and capitals.
> That's separate from the question about eliding zeros.
+1 on one of the latter versions, I don't care which one.
Yours,
Laurenz Albe
ore in the node a common prefix
> for all tuples in the node.
> Thanks for any advice,
Perhaps the PostGIS source will inspire you. They are compressing an
entry to its bounding box.
Yours,
Laurenz Albe
g or the databases from drifting apart.
Yours,
Laurenz Albe
of two-phase commit can make this bulletproof.
Is it worth adding additional complexity that is not a complete solution?
Yours,
Laurenz Albe
would
naturally think that the config files in /etc need to be handled manually,
but "postgresql.auto.conf" need not.
I am +1 on Tom's idea.
Yours,
Laurenz Albe
s are
> > certainly welcome. Otherwise, I'm hoping to commit this tomorrow.
>
> LGTM!
Cassandra (not the software) from the sidelines predicts that we will
get some fire from users for this, although I concede the theoretical
sanity of the change.
Yours,
Laurenz Albe
the fine-grained reset, but I am -1 on having that
reset "pg_stat_database.stats_reset". That would make the timestamp
mostly useless.
One could argue that resetting a single counter and *not* resetting
"pg_stat_database.stats_reset" would also be a lie, but at least it is
a
On Wed, 2022-03-23 at 21:31 +, Jacob Champion wrote:
> On Mon, 2022-03-07 at 11:44 +0100, Laurenz Albe wrote:
> > I am all for the idea, but you implemented the reverse of proposal 2.
> >
> > Wouldn't it be better to list the *rejected* authentication methods?
> > T
_str, total_size_str,
> percent);
I think you replied to the wrong thread...
Yours,
Laurenz Albe
that you found the oversight in LOCK - I wasn't even
aware that views could be locked.
Yours,
Laurenz Albe
═══
2022-03-27 21:00:00+02
(1 row)
test=> SELECT TIMESTAMPTZ '2022-03-26 20:00:00 Europe/Vienna' + INTERVAL '1
day';
?column?
2022-03-27 20:00:00+02
(1 row)
Yours,
Laurenz Albe
On Mon, 2022-03-14 at 13:40 +0100, Christoph Heiss wrote:
> On 3/9/22 16:06, Laurenz Albe wrote:
> > This paragraph contains a couple of grammatical errors.
>
> Replaced the two paragraphs with your suggestion, it is indeed easier to
> read.
>
> > Also, this
ND_VIEW
&& RelationHasSecurityInvoker(relation))
user_for_check = InvalidOid;
else
user_for_check = relation->rd_rel->relowner;
setRuleCheckAsUser((Node *) rule->actions, user_for_check);
setRuleCheckAsUser(rule->qual, user_for_check);
This might be easier to read.
Yours,
Laurenz Albe
then: you get to choose exactly one method
> that the client will accept.
I am all for the idea, but you implemented the reverse of proposal 2.
Wouldn't it be better to list the *rejected* authentication methods?
Then we could have "password" on there by default.
Yours,
Laurenz Albe
the same way that
Walter did, namely that this behaves just like security invoker functions.
But if the behavior is well documented, I think that is ok.
Yours,
Laurenz Albe
er to read. I
> wouldn't associate that with CHECK OPTION either. +1
Here is a new version, with improved documentation and the option renamed
to "check_permissions_owner". I just prefer the shorter form.
Yours,
Laurenz Albe
From e31ea3de2838dcfdc8c364fc08e54e5d37f00882 Mon Sep 17 00:
On Tue, 2022-02-15 at 16:07 +0100, walt...@technowledgy.de wrote:
> Laurenz Albe:
> > > I converted the option to run_as_owner=true|false in the attached v7.
> > > It now definitely seems like the right way to move forward and getting
> > > more feedback.
&g
E privileges on schemas are not
checked
+when referencing the underlying base relations, even if they are part of a
+different schema.
"referencing" is a bit unclear.
Perhaps "when checking permissions on the underlying base relations".
Otherwise, this looks good!
Yours,
Laurenz Albe
> definer and security invoker views - but this would be a big breaking
> change, which I don't think is acceptable.
I agree that changing the current behavior is not acceptable.
I guess more documentation how this works would be a good idea.
Not sure if this is the job of this patch, but since it exposes this
in new ways, it might as well clarify how all this works.
Yours,
Laurenz Albe
s_bob;
DROP USER IF EXISTS regress_rls_carol;
DROP USER IF EXISTS regress_rls_dave;
+DROP USER IF EXISTS regress_rls_grace;
But the name has to start with "e"!
I also see no reason to split a small patch like this into three parts.
In the attached, I dealt with the above and went
201 - 300 of 693 matches
Mail list logo
