On 7/26/24 10:35 PM, Jeff Davis wrote:
database_ctype_is_c refers to the LC_CTYPE environment of the database
-- pg_database.datctype. default_locale.ctype_is_c is the ctype of the
database's default collation.
Confusing, I know, but it matters for a few things that still depend on
the
Hello,
I hope this message finds you well. I am currently working on a PostgreSQL
extension and have encountered an issue where a static pointer becomes null
between different AM routines. My problem is as follows:
I am working with a few AM routines, specifically “ambuild” and “amrescan”.
Dave Cramer
On Sat, 27 Jul 2024 at 01:55, Tatsuo Ishii wrote:
> > So while the API's are "virtually" identical AFAICT there is no way to
> > create a "WITH HOLD" portal ?
>
> I am not sure if I fully understand your question but I think you can
> create a portal with "WITH HOLD" option.
>
>
On Thu, 2024-07-25 at 13:29 -0700, Jeff Davis wrote:
> it may be a good idea to version collation and ctype
> separately. The ctype version is, more or less, the Unicode version,
> and we know what that is for the builtin provider as well as ICU.
Attached a rough patch for the purposes of
Andrew Dunstan writes:
> As part of its 002_pgupgrade.pl, the pg_upgrade tests do a rerun of the
> normal regression tests. That in itself is sad, but what concerns me
> here is why it's so much slower than the regular run? This is apparent
> everywhere (e.g. on crake the standard run takes
As part of its 002_pgupgrade.pl, the pg_upgrade tests do a rerun of the
normal regression tests. That in itself is sad, but what concerns me
here is why it's so much slower than the regular run? This is apparent
everywhere (e.g. on crake the standard run takes about 30 to 90 s, but
On Wed, 24 Jul 2024 at 22:55, Heikki Linnakangas wrote:
>
> On 02/07/2024 07:49, David Rowley wrote:
> > I've attached a rebased set of patches. The previous set no longer applied.
>
> I looked briefly at the first patch. Seems reasonable.
>
> One little thing that caught my eye is that in
On 26/07/2024 23:01, Tristan Partin wrote:
Heikki asked me to take a look at this patchset for the commitfest.
Looks good to me.
Heikki, just be careful rebasing the first patch. You need to make sure
the newly set `required: false` gets carried forward.
Committed and backpatched to v16 and
On Thu, Jul 25, 2024 at 5:04 PM Alena Rybakina
wrote:
> To be honest, I have found a big problem in this patch - we try to perform
> the transformation every time we examime a column:
>
> for (indexcol = 0; indexcol < index->nkeycolumns; indexcol++) { ...
>
> }
>
> I have fixed it and moved the
Hi!
Cloudberry DB (Greenplum fork) uses IMMV feature for AQUMV (auto query
use matview) feature, so i got interested in how it is implemented.
On Thu, 11 Jul 2024 at 09:24, Yugo NAGATA wrote:
>
> I updated the patch to bump up the version numbers in psql and pg_dump codes
> from 17 to 18.
Few
On Friday, July 26, 2024, Ayush Vatsa wrote:
>
> I wanted to modify the SQL script of an extension by creating multiple
> objects within it.
> My aim is to make minimal changes to the existing script. To achieve this,
> I have created an
> external script and am attempting to run it within the
Hi PostgreSQL community,
I wanted to modify the SQL script of an extension by creating multiple
objects within it.
My aim is to make minimal changes to the existing script. To achieve this,
I have created an
external script and am attempting to run it within the extension script
using the \i
On 23.07.2024 15:53, Robert Haas wrote:
On Mon, Jul 22, 2024 at 5:19 PM Pavel Luzanov wrote:
Visible but inaccessible objects in system catalogs increase the volume
of command output unnecessarily. Why do I need to know the list of all
schemas in the database if I only have access to the
13 matches
Mail list logo
