efault privileges will be changed for objects created by
the current role.
Yours,
Laurenz Albe
ied. Perhaps:
[...]; if omitted, the current role is used.
Yours,
Laurenz Albe
;target_role" will *not* be assigned any
privileges.
Perhaps:
Default privileges are changed only for objects created by
target_role. If FOR ROLE
is omitted, the current role is assumed.
Yours,
Laurenz Albe
ot;that locking them"
+statement can be issued without the SKIP LOCKED clause
to ensure
+that no rows were overlooked. This technique has the additional benefit
that it can reduce
+the overal bloat of the updated table if the table can be vacuumed in
between batch updates.
+
"overal" --> "overall"
I don't think you should use "vacuum" as a verb.
Suggestion: "if you perform VACUUM on the table between
individual
update batches".
Yours,
Laurenz Albe
ot; or "not found" in the future.
I agree for names with underscores in them. But I think that quoting
is necessary for names like "timezone" or "datestyle" that might be
mistaken for normal words. My personal preference is to always quote
GUC names, but I think it is OK no
Thanks for having a look at my patch!
On Mon, 2023-10-30 at 15:03 -0700, David G. Johnston wrote:
> On Mon, Oct 30, 2023 at 2:50 PM David G. Johnston
> wrote:
> > On Tue, Oct 3, 2023 at 12:52 AM Laurenz Albe
> > wrote:
> > > On Mon, 2023-10-02 at
On Fri, 2023-10-27 at 16:08 -0700, Jeff Davis wrote:
> On Fri, 2023-10-27 at 08:48 +0200, Laurenz Albe wrote:
> > On Fri, 2023-10-13 at 15:33 -0400, Daniel Fredouille wrote:
> > > sorry it took me some time to reply. Yes, the patch is perfect if
> > > this is indeed
On Fri, 2023-10-27 at 11:34 +0200, Michael Banck wrote:
> On Fri, Oct 27, 2023 at 09:03:04AM +0200, Laurenz Albe wrote:
> > On Fri, 2022-11-04 at 10:49 +0100, Laurenz Albe wrote:
> > > On Thu, 2022-11-03 at 11:32 +0100, Laurenz Albe wrote:
> > > > On Wed, 2022-11-
ertainly should. That is an omission in 482675987b.
Go ahead and write a fix!
> Further to this: it seems that `Alter Subscription X Set(Run_As_Owner=True);`
> has no influence on the `subrunasowner` column of pg_subscriptions.
This seems to have been fixed in f062cddafe.
Yours,
Laurenz Albe
On Fri, 2022-11-04 at 10:49 +0100, Laurenz Albe wrote:
> On Thu, 2022-11-03 at 11:32 +0100, Laurenz Albe wrote:
> > On Wed, 2022-11-02 at 19:29 +, David Burns wrote:
> >
> > > Some additional clarity in the versions 14/15 documentation would be
> > > helpf
On Mon, 2023-01-09 at 16:40 +0100, Laurenz Albe wrote:
> > "Using ONLY to add or drop a constraint on only the partitioned table is
> > supported as long as there are no partitions. Once partitions exist, using
> > ONLY will result in an error. Instead, constraints on the pa
o fall between the cracks.
Yours,
Laurenz Albe
make
a row seem to vanish.
I cannot buy into the constraint argument. If the table owner wanted to
prevent you from causing a constraint violation error with a row you
cannot see, she wouldn't have given you a FOR UPDATE policy that allows
you to perform such an UPDATE.
Anyway, it is probably too late to change a behavior that has been like
that for a while and is not manifestly buggy.
Yours,
Laurenz Albe
certainly not to check new rows.
Yours,
Laurenz Albe
On Mon, 2023-10-23 at 22:43 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > On Mon, 2023-10-23 at 11:37 -0700, David G. Johnston wrote:
> > > I do believe that we should be against exposing, like in this case, any
> > > internal
> > > implementation detail t
er.
The correct way to do that would be to fake an ACL entry like
"laurenz=arwdDxt/laurenz"
if there is a NULL in the catalog, but that would add a ton of special-case
code to psql, which does not look appealing at all.
So we cannot completely hide the implementation, but perhaps "(default)" would
be less confusing than a NULL value.
If everybody agrees, I can modify the patch to do that.
Yours,
Laurenz Albe
t are you for or against "\pset null" to have its normal effect
on
the output of backslash commands in all other cases?
Speaking of consensus, it seems to me that Tom, Erik and me are in consensus.
Yours,
Laurenz Albe
On Mon, 2023-10-23 at 07:03 -0700, David G. Johnston wrote:
> On Monday, October 23, 2023, Laurenz Albe wrote:
> >
> > --- a/src/bin/psql/describe.c
> > +++ b/src/bin/psql/describe.c
> > @@ -6718,7 +6680,13 @@ static void
> > printACLColumn(PQE
base. If you use "make installcheck", that could
be a different locale.
I think that these tests are not absolutely necessary, and the other tests
are sufficient. Consequently, I took the simple road of removing them.
I also tried to improve the commit message.
Patch attached.
Your
nd I'd say that the regression tests should be
in "psql.sql" (not that it is very important).
I am not sure how to proceed. Perhaps it would indeed be better to have
two competing commitfest entries. Both could be "ready for committer",
and the committers can decide what they prefer.
Yours,
Laurenz Albe
>= 'a' AND t < 'd';
t
═══
a
c
(2 rows)
But the execution plan is identical...
I am not sure what is the problem here, but in my opinion the
operators shown in the execution plan should be like this:
SELECT * FROM tx WHERE t ~>=~ 'a' AND t ~<~ 'd';
t
════
a
e don't have a consensus.
I don't think I want to go ahead with my version of the patch unless
there is more support for it. I can review Erik's original code, if
that design meets with more favor.
> We should probably post on that thread that this one exists and post a link
> to it.
Perhaps a good idea, yes.
Yours,
Laurenz Albe
patch ever
gets committed.
I'd still like to wait for feedback from David before I change anything.
Yours,
Laurenz Albe
data directory.
I think it won't meet with favor if there are cases that require manual
intervention
for starting the server. That was the main argument for getting rid of the
exclusive
backup API, which had a similar problem.
Also, how do you envision two concurrent backups with your setup?
Yours,
Laurenz Albe
ng anything at
> all was very weak. Nobody was being forced to use them, and they broke
> nothing for people who didn't.
+1
Yours,
Laurenz Albe
that file will
be
included in the backup. How do you handle that during recovery? Ignore it if
another signal file is present? And if the user forgets to create a signal
file
for recovery, how do you prevent PostgreSQL from performing crash recovery?
Yours,
Laurenz Albe
On Sat, 2023-10-14 at 02:45 +0200, Erik Wienhold wrote:
> On 2023-10-09 09:54 +0200, Laurenz Albe write:
> >
> > I tinkered a bit with your documentation. For example, the suggestion to
> > "\pset null" seemed to be in an inappropriate place. Tell me what you
&
ent error message is more crypric than a plain
"you must have a signal file to start from a backup", so perhaps
your patch is a good idea.
Yours,
Laurenz Albe
s, reg* data types, ...).
What is inconvenient about storing the output of regprocedure?
Yours,
Laurenz Albe
On Mon, 2023-10-09 at 15:13 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > The whole point of this patch is to make psql behave consistently with
> > respect to
> > NULLs in meta-commands.
>
> Yeah. There is a lot of attraction in having \pset null affect the
On Mon, 2023-10-09 at 09:30 -0700, David G. Johnston wrote:
> On Mon, Oct 9, 2023 at 1:29 AM Laurenz Albe wrote:
> > On Sun, 2023-10-08 at 19:58 -0700, David G. Johnston wrote:
> >
> > > The built-in default privileges are only in effect if the object has not
>
> user's setting is incompatible.
I am not certain I understood you correctly.
Are you advocating for adding a mention of "\pset null" to every backslash
command
that displays privileges? That is excessive, in my opinion.
Yours,
Laurenz Albe
From 2afe3cbf674e163c146ea29582f7
On Mon, 2023-10-09 at 03:53 +0200, Erik Wienhold wrote:
> On 2023-10-08 06:14 +0200, Laurenz Albe write:
> > On Sat, 2023-10-07 at 20:41 +0200, Erik Wienhold wrote:
> > > > If you are happy enough with my patch, shall we mark it as ready for
> > > > committer?
leges at all, even for the object owner"
would be a better wording.
Perhaps it would also be good to mention this in the psql documentation.
Yours,
Laurenz Albe
On Sat, 2023-10-07 at 05:07 +0200, Erik Wienhold wrote:
> On 2023-10-06 22:32 +0200, Laurenz Albe write:
> > On Sun, 2023-09-17 at 21:31 +0200, Erik Wienhold wrote:
> > > I wrote a patch to change psql's display of zero privileges after a user's
> > > reported con
re was more support for
honoring "\pset null" rather than unconditionally displaying "(none)".
The simple attached patch does it like that. What do you think?
Yours,
Laurenz Albe
From 6c67f15f011ddf1e309cb7e84580b266d674a1e2 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date
On Fri, 2023-10-06 at 22:18 +0200, Laurenz Albe wrote:
> On Fri, 2023-10-06 at 22:16 +0200, Laurenz Albe wrote:
> > Here is a patch that does away with the special handling of NULL values
> > in psql backslash commands.
>
> Erm, I forgot to attach the p
On Fri, 2023-10-06 at 22:16 +0200, Laurenz Albe wrote:
> Here is a patch that does away with the special handling of NULL values
> in psql backslash commands.
Erm, I forgot to attach the patch.
Yours,
Laurenz Albe
From 6c67f15f011ddf1e309cb7e84580b266d674a1e2 Mon Sep 17 00:00:00 200
gt; other way to distinguish them if the difference matters.
>
> So +1 for me fixing \dp to honor "\pset null".
+1
Here is a patch that does away with the special handling of NULL values
in psql backslash commands.
Yours,
Laurenz Albe
On Fri, 2023-10-06 at 12:20 -0400, Bruce Momjian wrote:
> Good points, updated patch attached.
That patch is good to go, as far as I am concerned.
Yours,
Laurenz Albe
nt trigger) be implemented in an extension somehow, or is that not
> technically possible (I suspect not)?
You could perhaps use "object_access_hook" in an extension.
Yours,
Laurenz Albe
y to gain experience
is to review others' patches. In fact, you are expected to do that
if you submit your own.
Yours,
Laurenz Albe
atches).
About the UPDATE example:
-
I think that could go, because it is pretty similar to the previous
one. You even use ctid in both examples.
Status set to "waiting for author".
Yours,
Laurenz Albe
I propose the attached caution.
Yours,
Laurenz Albe
From b6abd7dfdf1e25515ead092489efde0d239f7053 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 3 Oct 2023 09:20:54 +0200
Subject: [PATCH] Document foreign key internals
Warn the user that foreign keys are implemented as triggers, and
that use
On Mon, 2023-10-02 at 09:49 -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > CREATE FUNCTION silly() RETURNS trigger LANGUAGE plpgsql AS 'BEGIN RETURN
> > NULL; END;';
> > CREATE TRIGGER silly BEFORE DELETE ON child FOR EACH ROW EXECUTE FUNCTION
> > silly();
>
&g
Perhaps it would be enough to run "RI_FKey_noaction_del" after
"RI_FKey_cascade_del", although that would impact the performance.
Yours,
Laurenz Albe
INTO parent VALUES (1);
INSERT INTO child VALUES (1);
DELETE FROM parent WHERE id = 1;
TABLE child;
id
1
(1 row)
The trigger function cancels the cascaded delete on "child", and we are left
with
a row in "child" that references no row in "parent".
Yours,
Laurenz Albe
On Sun, 2023-10-01 at 10:55 -0400, Andrew Dunstan wrote:
> Thanks, pushed.
Thanks for taking care of that.
Yours,
Laurenz Albe
ed, and again whenever the distribution of data in
> +their partitions changes significantly.
>
>
>
Yours,
Laurenz Albe
SQL behaves differently with other locks.
On the other hand, if nobody has complained about it in these ten years, perhaps
it is just fine the way it is, if by design or not.
Yours,
Laurenz Albe
On Fri, 2023-09-29 at 18:08 -0400, Bruce Momjian wrote:
> On Wed, Sep 6, 2023 at 05:53:56AM +0200, Laurenz Albe wrote:
> > > We may have different mental models here. This relates to the part
> > > that I wasn't keen on in your patch, i.e:
> > >
> > > +
Here is an improved version of the patch with regression tests.
Yours,
Laurenz Albe
From 71744ada1e2c8cfdbb57e03018572a1af623b09e Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Tue, 26 Sep 2023 10:09:49 +0200
Subject: [PATCH] Evaluate defaults in COPY FROM only if necessary
Since commit
On Mon, 2023-09-25 at 17:49 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2023-09-25 Mo 11:06, Andrew Dunstan wrote:
> > > On 2023-09-25 Mo 04:59, Laurenz Albe wrote:
> > > > CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
>
>
On Mon, 2023-09-25 at 09:54 +0200, Laurenz Albe wrote:
> In v16 and later, the following fails:
>
> CREATE TABLE boom (t character varying(5) DEFAULT 'a long string');
>
> COPY boom FROM STDIN;
> ERROR: value too long for type character varying(5)
>
> In PostgreSQL v
if
something that worked without an error in v15 starts to fail later on.
Yours,
Laurenz Albe
uot; when the
table has shrunk enough. Why not perform that task during vacuum truncation?
If vacuum truncation has taken place, check if the table size is no bigger
than "local_update_limit" * (1 + "autovacuum_vacuum_scale_factor"), and if
it is no bigger, reset "local_u
ex bloat is a show stopper
these days, when we have REINDEX CONCURRENTLY, so I am not worried.
Yours,
Laurenz Albe
On Mon, 2023-09-18 at 12:22 -0400, Robert Haas wrote:
> On Tue, Sep 5, 2023 at 11:15 PM Laurenz Albe wrote:
> > I don't think that is a good comparison. While most people probably
> > never need to touch "local_update_limit", "work_mem" is some
e thrown.
"escontext" is an ErrorSaveContext node, and it is the parser failing.
Not sure if we can do anything about that or if it is worth the effort.
Perhaps the documentation could reflect the implementation.
Yours,
Laurenz Albe
ot;.
Agreed, there are differences between partitions and normal tables.
And this is not the place in the documentation where we would like to
get into detail about the differences.
Attached is the next version of my patch.
Yours,
Laurenz Albe
From 33ef30888b5f5b57c776a1bd00065e0c94daccdb Mon Sep
eful.
To alleviate your concerns, perhaps it would help to describe the use case
and ideas for a good setting in the documentation.
Yours,
Laurenz Albe
On Thu, 2023-08-24 at 18:23 +0200, Matthias van de Meent wrote:
> On Wed, 19 Jul 2023 at 15:13, Thom Brown wrote:
> >
> > On Wed, 19 Jul 2023, 13:58 Laurenz Albe, wrote:
> > > I agree that the name "max_local_update" could be improved.
>
On Thu, 2023-08-17 at 09:37 +0900, Michael Paquier wrote:
> I have just noticed that we do not have a CF entry for this proposal,
> so I have added one with Laurenz as author:
> https://commitfest.postgresql.org/44/4504/
I have changed the author to Fujii Masao.
Yours,
Laurenz Albe
On Sat, 2023-07-08 at 08:11 +0200, Kim Johan Andersson wrote:
> On 07-07-2023 13:20, Laurenz Albe wrote:
> > I wrote:
> > > You implement both "SupportRequestIndexCondition" and
> > > "SupportRequestSimplify",
> > > but when
boolvacuum_truncate;/* enables vacuum to truncate a relation */
+ int max_local_update; /* Updates to pages after this block must
go through the VM */
} StdRdOptions;
#define HEAP_MIN_FILLFACTOR10
In the comment, it should be FSM, not VM, right?
Other than that, I see nothing wrong.
Yours,
Laurenz Albe
ICU.
But this was reverted in 2535c74b1a6190cc42e13f6b6b55d94bff4b7dd6.
Yours,
Laurenz Albe
\ev or \ef, right?
Yours,
Laurenz Albe
quot;, for example
Index Cond (expr >= lower(range) AND expr < upper(range)).
Yours,
Laurenz Albe
e
> useful.
Right, I agree. A GUC/storage parameter like "update_strategy"
that is an enum (try-hot | first-page | ...).
To preserve BRIN indexes or CLUSTERed tables, there could be an additional
"insert_strategy", but that would somehow have to be tied to a certain
index. I think that is out of scope for this effort.
Yours,
Laurenz Albe
termine which collation to use for string comparison
HINT: Use the COLLATE clause to set the collation explicitly.
The replacement operators are wrong; it should be ~>=~ and ~<~ .
Also, there should be no error message.
The result should be 'a', 'c' and 'ch'.
Yours,
Laurenz Albe
NGE ||
req->funcid == F_RANGE_CONTAINS_ELEM);
if (req->funcid == F_ELEM_CONTAINED_BY_RANGE)
{
[...]
}
else if (req->funcid == F_RANGE_CONTAINS_ELEM)
{
[...]
}
Yours,
Laurenz Albe
"Allow forcing UPDATEs off the same page".
I've been thinking about the same thing - an option that changes the update
strategy to always use the lowest block with enough free space.
That would allow to consolidate bloated tables with no down time.
Yours,
Laurenz Albe
On Sun, 2023-07-02 at 20:13 +0200, Tomas Vondra wrote:
> FWIW I've pushed the fix prepared by James a couple days ago. Thanks for
> the report!
Thanks, and sorry for being pushy.
Yours,
Laurenz Albe
ppy to let you take it -- got lots of other stuff on my plate.
>
> OK, will do.
It would be cool if we could get that into the next minor release in August.
Yours,
Laurenz Albe
pgrade_testing/postgres_14/new_pg
> 11224524 /home/test/pradeep_test/pg_upgrade_testing/postgres_11.4/master
> 41952 /home/test/pradeep_test/pg_upgrade_testing/postgres_14/new_pg
That looks fine. The files exist only once, and the 41MB that only exist in
the new data directory are catalog data and other stuff that is different
on the new cluster.
Yours,
Laurenz Albe
n a significant increase in the new
> cluster's size.
Please provide some numbers, ideally
du -sk
Yours,
Laurenz Albe
r all but analytic workloads.
Yours,
Laurenz Albe
; public | parttest_10_7 | fdw_node5
> public | parttest_10_9 | fdw_node6
> (5 rows)
>
> (Muffled sound of small patch hatching) aha:
>
> postgres=# SELECT * FROM parttest;
> ERROR: user mapping not found for user "postgres", server "fdw_node5"
+1
Yours,
Laurenz Albe
sg("Damn1! Update were done
> in a non-volatile function")));
I think it is project policy to start error messages with a lower case
character.
Yours,
Laurenz Albe
_state = NULL;
}
if (node->prefixsort_state != NULL)
{
- tuplesort_reset(node->prefixsort_state);
+ tuplesort_end(node->prefixsort_state);
node->prefixsort_state = NULL;
}
The original comment hints that this might mot be the correct thing to do...
Yours,
Laurenz Albe
y tests show that it is calculated
> at execution time.
Ah, ok, then sorry for the noise. I misread the code then.
Yours,
Laurenz Albe
uthor, I'd say that that sounds reasonable, particularly
in case #1. If the postmaster dies, we are going to die too, so it
probably doesn't matter much. But I think an error is certainly also
correct in that case.
Yours,
Laurenz Albe
n explicitly.
>
> We have never seen this before. Could this be a bug?
Impossible to say without a way to reproduce.
Yours,
Laurenz Albe
be faily trivial, if not very useful.
At a quick glance, it looks like you resolve "timezone" at the time
the query is parsed. Shouldn't the resolution happen at query
execution time?
Yours,
Laurenz Albe
t; > this feature useful.
>
> Please see attached the patch that introduces this new feature.
Can you explain why *you* would find this feature useful?
Yours,
Laurenz Albe
w view and define the order of fields if we need
> to display the fields of table in a order of our demand, it is not a
> good way.
But PostgreSQL tables are not spreadsheets. When, except in the display of
the result of interactive queries, would the order matter?
Yours,
Laurenz Albe
On Thu, 2023-05-18 at 16:49 -0400, Bruce Momjian wrote:
> I have completed the first draft of the PG 16 release notes.
I found two typos.
Yours,
Laurenz Albe
diff --git a/doc/src/sgml/release-16.sgml b/doc/src/sgml/release-16.sgml
index faecae7c42..7dad0b8550 100644
--- a/doc/src/sgml/release
g │ pg_get_viewdef │ text │ text, boolean
│ func
(17 rows)
A server function can be conveniently called from any client code.
Yours,
Laurenz Albe
hat isn't normally part of "psql"
output.
"okbob" should be "Pavel Stehule".
Yours,
Laurenz Albe
u','x'))
> > WHERE c.oid = '21949943' AND c.oid = i.indrelid AND i.indexrelid = c2.oid
> > ORDER BY i.indisprimary DESC, c2.relname;
> > -- **
>
> This looks little bit strange
>
> What about /* comments
>
> Like
>
> /*** Query /
>
> Or just
>
> Query
+1 for either of Pavel's suggestions.
Yours,
Laurenz Albe
out and hot_standby_feedback = on
on the standby instead.
That should have pretty much the same effect, and it is measured in
time and not in the number of transactions.
Yours,
Laurenz Albe
;
> +1 for removing.
I am not against this in principle, but I know that there are people using
this parameter; see the discussion linked in
https://postgr.es/m/e1jkzxe-0006dw...@gemulon.postgresql.org
I can't say if they have a good use case for that parameter or not.
Yours,
Laurenz Albe
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
101 - 200 of 685 matches
Mail list logo
