On 2022-Feb-14, Peter Eisentraut wrote:
> On 11.02.22 13:51, Julien Rouhaud wrote:
> > > > I'm wondering why you changed this function to return an ObjectAddress
> > > > rather
> > > > than an Oid? There's no event trigger support for ALTER DATABASE, and
> > > > the rest
> > > > of similar
On 14.02.22 10:14, Julien Rouhaud wrote:
Do you plan to send a rebased version of the ICU default collation
soon or should I start looking at the current v4?
I will send an updated patch in the next few days.
Hi,
On Mon, Feb 14, 2022 at 09:55:19AM +0100, Peter Eisentraut wrote:
> I have committed this patch.
Great! Do you plan to send a rebased version of the ICU default collation
soon or should I start looking at the current v4?
> I didn't address the above issue. I looked at it a bit, but I also
On 11.02.22 13:51, Julien Rouhaud wrote:
I'm wondering why you changed this function to return an ObjectAddress rather
than an Oid? There's no event trigger support for ALTER DATABASE, and the rest
of similar utility commands also returns Oid.
Hmm, I was looking at RenameDatabase() and
On Fri, Feb 11, 2022 at 12:07:02PM +0100, Peter Eisentraut wrote:
> On 10.02.22 12:08, Julien Rouhaud wrote:
> > > + errhint("Rebuild all objects affected
> > > by collation in the template database and run "
> > > +
On 10.02.22 12:08, Julien Rouhaud wrote:
+errhint("Rebuild all objects affected by
collation in the template database and run "
+"ALTER DATABASE %s REFRESH
COLLATION VERSION, "
+
checking in createdb()
Thanks! All issues are indeed fixed. I just have a few additional comments:
> From 290ebb9ca743a2272181f435d5ea76d8a7280a0a Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut
> Date: Thu, 10 Feb 2022 09:44:20 +0100
> Subject: [PATCH v4] Database
: Peter Eisentraut
Date: Thu, 10 Feb 2022 09:44:20 +0100
Subject: [PATCH v4] Database-level collation version tracking
This adds to database objects the same version tracking that collation
objects have. There is a new pg_database column datcollversion that
stores the version, a new function
On Wed, Feb 09, 2022 at 05:12:41PM +0100, Peter Eisentraut wrote:
> On 08.02.22 13:55, Julien Rouhaud wrote:
> > Apart from that I still think that we should check the collation version of
> > the
> > source database when creating a new database. It won't cost much but will
> > give
> > the DBA
On 2022-Feb-08, Julien Rouhaud wrote:
> On Tue, Feb 08, 2022 at 12:14:02PM +0100, Peter Eisentraut wrote:
> > I don't think you can run ALTER DATABASE from the regression test scripts,
> > since the database name is not fixed. You'd have to paste the command
> > together using psql tricks or
On 08.02.22 13:55, Julien Rouhaud wrote:
Apart from that I still think that we should check the collation version of the
source database when creating a new database. It won't cost much but will give
the DBA a chance to recreate the indexes before risking invalid index usage.
A question on
On Wed, Feb 09, 2022 at 12:48:35PM +0100, Peter Eisentraut wrote:
> On 08.02.22 13:55, Julien Rouhaud wrote:
> > I'm just saying that without such a lock you can easily trigger the "cache
> > lookup" error, and that's something that's supposed to happen with normal
> > usage I think. So it should
On 08.02.22 13:55, Julien Rouhaud wrote:
I'm just saying that without such a lock you can easily trigger the "cache
lookup" error, and that's something that's supposed to happen with normal
usage I think. So it should be a better message saying that the database has
been concurrently dropped,
On Mon, Feb 07, 2022 at 04:44:24PM +0100, Peter Eisentraut wrote:
> On 07.02.22 11:29, Julien Rouhaud wrote:
> > - that's not really something new with this patch, but should we output the
> >collation version info or mismatch info in \l / \dO?
>
> It's a possibility. Perhaps there is a
On Tue, Feb 08, 2022 at 12:14:02PM +0100, Peter Eisentraut wrote:
> On 07.02.22 17:08, Julien Rouhaud wrote:
> > There's so limited testing in collate.* regression tests, so I thought it
> > would
> > be ok to add it there. At least some ALTER DATABASE ... REFRESH VERSION
> > would
> > be good,
On 07.02.22 17:08, Julien Rouhaud wrote:
There's so limited testing in collate.* regression tests, so I thought it would
be ok to add it there. At least some ALTER DATABASE ... REFRESH VERSION would
be good, similarly to collation-level versioning.
I don't think you can run ALTER DATABASE
On Mon, Feb 07, 2022 at 04:44:24PM +0100, Peter Eisentraut wrote:
> On 07.02.22 11:29, Julien Rouhaud wrote:
>
> > - there is no test
>
> Suggestions where to put it? We don't really have tests for the
> collation-level versioning either, do we?
There's so limited testing in collate.*
7 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 7 Feb 2022 16:32:19 +0100
Subject: [PATCH v3] Database-level collation version tracking
This adds to database objects the same version tracking that collation
objects have. There is a new pg_database column datcollversion that
stores the vers
aster.
>From 718942496eb0fa19ab092e3c74af42149f86f756 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Tue, 1 Feb 2022 16:09:30 +0100
Subject: [PATCH v2] Database-level collation version tracking
This adds to database objects the same version tracking that collation
objects have. Ther
: Peter Eisentraut
Date: Tue, 1 Feb 2022 16:09:30 +0100
Subject: [PATCH] Database-level collation version tracking
This adds to database objects the same version tracking that collation
objects have. There is a new pg_database column datcollversion that
stores the version, a new function
20 matches
Mail list logo
