> Regina Obe писал(а) 2025-01-03 23:08:
> > I tested this with a patched version of the EDB PG 17 installer that
> > includes this patch and it fixed the issue I was having described in:
> >
> > https://www.postgresql.org/message-
> id/01db1df8%2449765bb0
I tested this with a patched version of the EDB PG 17 installer that includes
this patch and it fixed the issue I was having described in:
https://www.postgresql.org/message-id/01db1df8%2449765bb0%24dc631310%24%40pcorp.us
It would be great if this was backported to PG17.
The new status of t
I'm not sure what the issue is here exactly, if it's a bug in Meson VC++ or
something in pgSphere code.
I've managed to build pg_sphere binaries under mingw64 and load them and
regress fine In PostgreSQL EDB VC++ for versions 14-16.
However when I tried PG17, the create extension pg_sphere fails
> > I think it ends up doing a copy thus the copy error in my log failures
> > which don't exist anywhere in the Makefil
> >
> > cp -pR ../../backend/storage/lmgr/lwlocknames.h
> >
> > Sorry for not checking on a linux system. I was thinking I should have done
> that first.
>
> Ah yeah, that's pe
> > I think I got something not too far off from what's there now that works
> under my msys2 setup again. This is partly using your idea of using
> $(top_builddir) to qualify the path but in the LN_S section that is causing me
> grief.
> > This seems to work okay building in tree and out of tree.
> > Hi Regina,
> >
> > On 2024-Mar-27, Regina Obe wrote:
> >
> > > The error is
> > >
> > > rm -f '../../src/include/storage/lwlocknames.h'
> > > cp -pR ../../backend/storage/lmgr/lwlocknames.h
> > > '../../
> Hi Regina,
>
> On 2024-Mar-27, Regina Obe wrote:
>
> > The error is
> >
> > rm -f '../../src/include/storage/lwlocknames.h'
> > cp -pR ../../backend/storage/lmgr/lwlocknames.h
> > '../../src/include/storage/lwlocknames.h'
> >
> Hi Regina,
>
> On 2024-Mar-27, Regina Obe wrote:
>
> > The error is
> >
> > rm -f '../../src/include/storage/lwlocknames.h'
> > cp -pR ../../backend/storage/lmgr/lwlocknames.h
> > '../../src/include/storage/lwlocknames.h'
> >
> On Thu, 28 Mar 2024 at 04:34, Regina Obe wrote:
> > CREATE TABLE edge_data AS
> > SELECT i AS edge_id, i + 1 AS start_node, i + 2 As end_node FROM
> > generate_series(1,10) AS i;
> >
> > WITH edge AS (
> > SELECT start_node, end_node
> >
I've been having trouble compiling PG 17 using msys2 / mingw64 (sorry my
meson setup is a bit broken at moment, so couldn't test that.).
Both my msys2 envs (Rev2, Built by MSYS2 project) 13.2.0 and my older
setup (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
Have the same issue:
Th
Our PostGIS bot that follows master branch has been crashing for past couple
of days on one of our tests
https://trac.osgeo.org/postgis/ticket/5701
I traced the issue down to this commit:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=66c0185a3d14b
bbf51d0fc9d267093ffec735231
Th
> > On 1 Aug 2023, at 20:45, Robert Haas wrote:
> >
> > On Tue, Aug 1, 2023 at 2:24 PM Daniel Gustafsson
> wrote:
> >> returned with feedback. Please feel free to resubmit to a future CF
> >> when there is a new version of the patch.
> >
> > Isn't the real problem here that there's no consensus
> It isn't. ZDB, and I think (at least) PostGIS, have their own "version()"
function.
> Keeping everything the same version keeps me "sane" and eliminates a class
> of round-trip questions with users.
>
Yes we have several version numbers and yes we too like to keep the
extension version the same
>
> > As for Tom's concern about downgrades, I think it's valid but it's a
> > case that is easy to test for in Plpgsql and either handle or error.
> > For example, we use semver so testing for a downgrade at the top of
> > the upgrade script is trivial.
>
I was thinking about this more. The ex
> This change also makes it easier for extensions that use versioned .so files
> (by that I mean uses extension-.so rather than extension.so).
> Because such extensions can't really use the chaining property of the
> existing upgrade system and so need to write a direct X--Y.sql migration file
> > My opinion is that the switch to using ICU by default is ill-advised
> > and should be reverted.
>
> Most of the complaints seem to be complaints about v15 as well, and while
> those complaints may be a reason to not make ICU the default, they are also
> an argument that we should continue to
> Yeah. My recommendation is just LOCALE:
>
> regression=# CREATE DATABASE test1 TEMPLATE=template0 ENCODING =
> 'UTF8' LOCALE = 'C'; CREATE DATABASE regression=# CREATE DATABASE test2
> TEMPLATE=template0 ENCODING = 'UTF8' ICU_LOCALE = 'C';
> NOTICE: using standard form "en-US-u-va-posix" for l
> > CREATE DATABASE test TEMPLATE=template0 ENCODING = 'UTF8'
> LC_COLLATE = 'C'
> > LC_CTYPE = 'C';
>
> As has been pointed out already, setting LC_COLLATE/LC_CTYPE is
> meaningless when the locale provider is ICU. You need to look at what ICU
> locale is being chosen, or force it with LOCALE =
> Peter Eisentraut writes:
> > If the database is created with locale provider ICU, then lc_collate
> > does not apply here, so the result might be correct (depending on what
> > locale you have set).
>
> FWIW, an installation created under LANG=C defaults to ICU locale en-US-u-
> va-posix for me
A couple of days ago, our PostGIS PG16 bots started failing with order
changes in text.
We have our tests set to locale=c
It seems since April 20th, our tests that rely on sorting characters
changed.
As noted in this ticket:
https://trac.osgeo.org/postgis/ticket/5375
I'm assuming it's result of
> Here are my thoughts of how this can work to satisfy our specific needs
and
> that of others who have many micro versions.
>
> 1) We define an additional file. I'll call this a paths file
>
> So for example postgis would have a
>
> postgis.paths file
>
> The format of the path file would be
Here are my thoughts of how this can work to satisfy our specific needs and
that of others who have many micro versions.
1) We define an additional file. I'll call this a paths file
So for example postgis would have a
postgis.paths file
The format of the path file would be of the form
, => 3
> Personally I don't see the benefit of 1 big file vs. many 0-length files
to justify
> the cost (time and complexity) of a PostgreSQL change, with the
> corresponding cost of making use of this new functionality based on
> PostgreSQL version.
>
>From a packaging stand-point 1 big file is better
> Packager might actually know better in that they could ONLY consider the
> packages ever packaged by them.
>
I'm a special case packager cause I'm on the PostGIS project and I only
package postgis related extensions, but even I find this painful.
But for most packagers, I think they are juggli
> On Mon, Apr 03, 2023 at 09:26:25AM +0700, Yurii Rashkovskii wrote:
> > I want to chime in on the issue of lower-number releases that are
> > released after higher-number releases. The way I see this particular
> > problem is that we always put upgrade SQL files in release "packages,"
> > and they
> Pushed with some mostly-cosmetic adjustments (in particular I tried to
make
> the docs and tests neater).
>
> I did not commit the changes in get_available_versions_for_extension
> to add no_relocate as an output column. Those were dead code because you
> hadn't done anything to connect them up
> On Sat, Mar 11, 2023 at 03:18:18AM -0500, Regina Obe wrote:
> > Attached is a revised patch with these changes in place.
>
> I've given a try to this patch. It builds and regresses fine.
>
> My own tests also worked fine. As long as ext1 was found in the ext2's
> > I wonder if a solution to this problem might be to provide some kind
> > of a version map file. Let's suppose that the map file is a bunch of
> > lines of the form X Y Z, where X, Y, and Z are version numbers. The
> > semantics could be: we (the extension authors) promise that if you
> > want t
> I've given a try to this patch. It builds and regresses fine.
>
> My own tests also worked fine. As long as ext1 was found in the ext2's
> no_relocate list it could not be relocated, and proper error message is
given
> to user trying it.
>
> Nitpicking, there are a few things that are weird to
> Subject: Re: Ability to reference other extensions by schema in extension
> scripts
>
> "Regina Obe" writes:
> >> requires = 'extfoo, extbar'
> >> no_relocate = 'extfoo'
>
> > So when no_relocate is specified, where would t
> "Regina Obe" writes:
> >> requires = 'extfoo, extbar'
> >> no_relocate = 'extfoo'
>
> > So when no_relocate is specified, where would that live?
>
> In the control file.
>
> > Would I mark the extfoo as not reloca
> No, pg_depend is not the thing to use for this. I was thinking of a new
field in
> the extension's control file, right beside where it says it's dependent on
such-
> and-such extensions in the first place. Say like
>
> requires = 'extfoo, extbar'
> no_relocate = 'extfoo'
>
So whe
> "Regina Obe" writes:
> > [ 0005-Allow-use-of-extschema-reqextname-to-reference.patch ]
>
> I took a look at this. I'm on board with the feature design, but not so
much
> with this undocumented restriction you added to ALTER EXTENSION SET
> SCHEMA:
&
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Friday, March 10, 2023 3:07 PM
> To: Regina Obe
> Cc: 'Gregory Stark (as CFM)' ; 'Sandro Santilli'
> ; pgsql-hackers@lists.postgresql.org; 'Regina Obe'
>
>
> I wonder if a solution to this problem might be to provide some kind of a
> version map file. Let's suppose that the map file is a bunch of lines of the
> form
> X Y Z, where X, Y, and Z are version numbers. The semantics could be: we (the
> extension authors) promise that if you want to upgrade
> I'm not unsympathetic to the idea of trying to support multiple upgrade paths
> in one script. I just don't like this particular design for that, because it
> requires the extension author to make promises that nobody is actually going
> to deliver on.
>
> regards, tom lan
> The thing that confuses me here is why the PostGIS folks are ending up with
> so many files.
> We certainly don't have that problem with the extension that
> are being maintained in contrib, and I guess there is some difference in
> versioning practice that is making it an issue for them but not
> It looks like this patch needs a quick rebase, there's a conflict in the
> meson.build.
>
> I'll leave the state since presumably this would be easy to resolve but it
> would
> be more likely to get attention if it's actually building cleanly.
>
> http://cfbot.cputube.org/patch_42_4023.log
> -
> It looks like this patch needs a quick rebase, there's a conflict in the
> meson.build.
>
> I'll leave the state since presumably this would be easy to resolve but it
> would
> be more likely to get attention if it's actually building cleanly.
>
> http://cfbot.cputube.org/patch_42_4023.log
>
> This patch too is conflicting on meson.build. Are these two patches
> interdependent?
>
> This one looks a bit more controversial. I'm not sure if Tom has been
> convinced and I haven't seen anyone else speak up.
>
> Perhaps this needs a bit more discussion of other options to solve this issue.
> On Sun, Feb 26, 2023 at 01:39:24AM -0500, Regina Obe wrote:
>
> > > 1) Just don't allow any extensions referenced by other
> > >extensions to be relocatable.
> >
> > Attached is my revision 3 patch, which follows the proposed #1.
> > Don'
> So in conclusion we have 3 possible paths to go with this
>
> 1) Just don't allow any extensions referenced by other extensions to be
> relocatable.
> It will show a message something like
> "SET SCHEMA not allowed because other extensions depend on it"
> Given that if you don't specify relocata
> On Mon, Feb 06, 2023 at 05:19:39AM -0500, Regina Obe wrote:
> >
> > Attached is a revised version of the original patch. It is revised to
> > prevent
> >
> > ALTER EXTENSION .. SET SCHEMA if there is a dependent extension that
> > referenc
> > > Here is first version of my patch using the
> > > @extschema:extensionname@ syntax you proposed.
> > >
> > > This patch includes:
> > > 1) Changes to replace references of @extschema:extensionname@ with
> > > the schema of the required extension
> > > 2) Documentation for the feature
> > > 3)
> On Mon, Jan 16, 2023 at 11:57:30PM -0500, Regina Obe wrote:
>
> > What would be more bullet-proof is having an extra column in
> > pg_extension or adding an extra array element to
> > pg_extension.extcondition[] that allows you to say "Hey, don't allow
>
>
> On Thu, Dec 15, 2022 at 08:04:22AM -0500, Regina Obe wrote:
> > > On Tue, Nov 22, 2022 at 11:24:19PM -0500, Regina Obe wrote:
> > >
> > > > If an extension is required by another extension and that required
> > > > extension schema
> Sandro Santilli writes:
> > On Mon, Jan 09, 2023 at 05:51:49PM -0500, Tom Lane wrote:
> >> ... you still need one script file for each supported upgrade step
>
> > That's exactly the problem we're trying to solve here.
> > The include support is nice on itself, but won't solve our problem.
>
>
> I continue to think that this is a fundamentally bad idea. It creates all
sorts of
> uncertainties about what is a valid update path and what is not.
Restrictions
> like
>
> + Such wildcard update
> + scripts will only be used when no explicit path is found from
> + old to target ve
> On Tue, Nov 22, 2022 at 11:24:19PM -0500, Regina Obe wrote:
>
> > Here is first version of my patch using the @extschema:extensionname@
> > syntax you proposed.
> >
> > This patch includes:
> > 1) Changes to replace references of @extschema:extensionname@
>
> "Regina Obe" writes:
> >> I have a distinct sense of deja vu here. I think this idea, or
> >> something isomorphic to it, was previously discussed with some other
> syntax details.
>
> > I found the old discussion I recalled having and Steph
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
I reviewed this patch
https://www.postgresql.org/message-id/
> On Sun, Nov 13, 2022 at 11:46:50PM -0500, Regina Obe wrote:
> > > Re: Sandro Santilli
> > > > I'm attaching an updated version of the patch. This time the patch
> > > > is tested. Nothing changes unless the .control file for the
> > > > subje
> Re: Sandro Santilli
> > I'm attaching an updated version of the patch. This time the patch is
> > tested. Nothing changes unless the .control file for the subject
> > extension doesn't have a "wildcard_upgrades = true" statement.
> >
> > When wildcard upgrades are enabled, a file with a "%" symbo
> "Regina Obe" writes:
> >> I have a distinct sense of deja vu here. I think this idea, or
> >> something isomorphic to it, was previously discussed with some other
> syntax details.
>
> > I found the old discussion I recalled having and Stephen had su
Apologies. I made a mistake on my downgrade test.
So 3 should be
3) It is possible to downgrade with the wildcard. For example I had
paths
wildtest--%--2.1.sql
and confirmed it used the downgrade path when going from 2.2 to 2.1
> "Regina Obe" writes:
> > My proposal is this. If you think it's a good enough idea I can work
> > up a patch for this.
> > Extensions currently are allowed to specify a requires in the control
file.
> > I propose to use this in
I think I had brought this up a while ago, but I forget what the opinion was
on the matter.
PostGIS has a number of extensions that rely on it. For the extensions that
are packaged with PostGIS, we force them all into the same schema except for
the postgis_topology and postgis_tiger_geocoder exte
Just to reiterate the main impetus for this patch is to save PostGIS from
shipping 100s of duplicate extension files for each release.
> And now with the actual patch attached ... (sorry)
>
> --strk;
>
Sandro, can you submit an updated version of this patch.
I was testing it out and looked goo
e proposal (which is wider than the patch) ?
>
> --strk;
>
> Libre GIS consultant/developer
> https://strk.kbt.io/services.html
[Regina Obe]
Just a heads up about the above, Sandro has added it as a commitfest item
which hopefully we can polish in time for PG16.
https://commitfest.p
Is this intentional behavior?
-- I can do this
SELECT substring('3.2.0' from '[0-9]*\.([0-9]*)\.');
-- But can't do this gives error syntax error at or near "from"
SELECT pg_catalog.substring('3.2.0' from '[0-9]*\.([0-9]*)\.');
-- but can do
SELECT pg_catalog.substring('3.2.0', '[0-9]*\.([0-9]*
> Presumably 15 years out from the 1.x -> 2.x we can stop worrying about
> bundling unpackaged postgis into an extension, and just recommend a hard
> upgrade dump/restore to the hardy souls still running 1.x.
>
> P.
>
We don't need to worry about 1.x cause 1.x can only do a hard upgrade to 2 or
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
No need for documentation as this is a performance improvement pa
> I think there are probably other ways of fixing this query that won't have
> such dramatic effects; it doesn't really seem to need to use WITH, and I bet
> you could also tweak the WITH query to prevent inlining.
Yes I know I can change THIS QUERY. I've changed other ones to work around
this
The CTE change in PostgreSQL 12 broke several of PostGIS regression tests
because many of our tests are negative tests that test to confirm we get
warnings in certain cases. In the past, these would output 1 notice because
the CTE was materialized, now they output 1 for each column.
An example is
>
> > a) In this particular case, I have a function that uses fuzzystrmatch
and is
> used in functional indexes.
> > I unfortunately can't schema qualify the use of soundex, because I
> > don't know where the user may have installed fuzzystrmatch is
> > installed
> > b) Stephen Frost had suggested
> From: Paul Ramsey [mailto:pram...@cleverelephant.ca]
> Sent: Monday, July 23, 2018 2:42 PM
> To: Regina Obe
> Subject: Fwd: "interesting" issue with restore from a pg_dump with a
> database-wide search_path
>
> Seen this one?
> P
>
>
> -- Fo
> "Regina Obe" writes:
> > Here is a trivial example to exercise that doesn't involve PostGIS.
>
> > CREATE TABLE edge AS SELECT 1 AS edge_id; SELECT 't3280', 'L1b' ||
> > generate_series(1,10) FROM edge ORDER BY 1;
>
> That'
> On 29 June 2018 at 21:06, Regina Obe wrote:
> > I think the exact query that is triggering it is this one though I
> > don't have PostgreSQL 10 head installed locally to confirm.
> >
> > SELECT 't3280', 'L1b' || topology.TopoGeo_AddLine
On June 26th, our PostGIS debian bot started failing on PostgreSQL 10 with
one of our regression tests for topology.
It started erroring out with
ORDER/GROUP BY expression not found in targetlist
Related ticket here: https://trac.osgeo.org/postgis/ticket/4111
I think the exact query that is tr
On December 13th this change to context creation was committed, which broke
PostGIS trunk compile against PostgreSQL 11 head.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9fa6f00b1308d
d10da4eca2f31ccbfc7b35bb461
Ticketed in PostGIS here:
https://trac.osgeo.org/postgis/ticket/3
70 matches
Mail list logo
