Hi,
I have trying to upgrade from postgis 2.4.1 to postgis 2.4.6 for PG 10
sever. I am getting the following error when doing in alter command..
*ALTER EXTENSION postgis_topology UPDATE;*
ERROR: column proc.prokind does not exist
LINE 15: ... = 'e' and e.extname = $1 and c.relname = $2 AND (proc
Hi Ahsan,
It seems there is some error with the version detection mechanism as
it's detecting PG11+.
Can you please check what's the output of:
{{{
Select CASE WHEN split_part(s,'.',1)::integer > 9 THEN
split_part(s,'.',1) || '0' ELSE split_part(s,'.', 1) ||
split_part(s,'.', 2) END AS v
FROM sub
I see, thank you very much for these enlightenments.
I think it would be nice to add this support to PostGIS. I think it is
possible to mix PostGIS Topology and PgRouting to get a similar result so
maybe it does not worth it. I will try such a mix when I have some time.
Thanks again,
Regards,
Adrie
Select CASE WHEN split_part(s,'.',1)::integer > 9 THEN
db1-# split_part(s,'.',1) || '0' ELSE split_part(s,'.', 1) ||
db1-# split_part(s,'.', 2) END AS v
db1-# FROM substring(version(), 'PostgreSQL ([0-9\.]+)') AS s;
v
---
(1 row)
On Mon, Jan 14, 2019 at 2:35 PM Raúl Marín Rodríguez
wrote:
> Hi
What does `Select version()` show?
On Mon, Jan 14, 2019 at 11:46 AM Ahsan Hadi wrote:
>
> Select CASE WHEN split_part(s,'.',1)::integer > 9 THEN
> db1-# split_part(s,'.',1) || '0' ELSE split_part(s,'.', 1) ||
> db1-# split_part(s,'.', 2) END AS v
> db1-# FROM substring(version(), 'PostgreSQL ([0-
On Mon, Jan 14, 2019 at 3:53 PM Raúl Marín Rodríguez
wrote:
> What does `Select version()` show?
>
it is PG 10.6
>
> On Mon, Jan 14, 2019 at 11:46 AM Ahsan Hadi
> wrote:
> >
> > Select CASE WHEN split_part(s,'.',1)::integer > 9 THEN
> > db1-# split_part(s,'.',1) || '0' ELSE split_part(s,'.',
> it is PG 10.6
Can you share the full string? It seems there is an issue with the
pattern matching.
--
Raúl Marín Rodríguez
carto.com
___
postgis-users mailing list
postgis-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users
On Mon, Jan 14, 2019 at 4:15 PM Raúl Marín Rodríguez
wrote:
> > it is PG 10.6
>
> Can you share the full string? It seems there is an issue with the
> pattern matching.
>
We are testing with EnterpriseDB's version of PG but in PG it would be
PostgreSQL 10.6.
It seems that it is looking for a ca
Hi Ashan,
are you able to provide the exact string being reported to 'select
version()'? A screen shot or photo will be good. (rephrased "it's going to
be ..." not.)
пн, 14 янв. 2019 г. в 14:46, Ahsan Hadi :
> On Mon, Jan 14, 2019 at 4:15 PM Raúl Marín Rodríguez <
> rmrodrig...@carto.com> wrote:
> We are testing with EnterpriseDB's version of PG but in PG it would be
> PostgreSQL 10.6.
Does EnterpriseDB's fork change the output of version(). If so, that's
the issue.
--
Raúl Marín Rodríguez
carto.com
___
postgis-users mailing list
postgis-user
On Mon, Jan 14, 2019 at 4:57 PM Raúl Marín Rodríguez
wrote:
> > We are testing with EnterpriseDB's version of PG but in PG it would be
> PostgreSQL 10.6.
>
> Does EnterpriseDB's fork change the output of version(). If so, that's
> the issue.
>
That's the string...
EnterpriseDB 10.6.13
I don't
> I don't think we have faced this issue with upgrade in the past...
Before PG11, Postgis didn't need to check the Postgresql release at runtime
in the SQL code. As a reference, in the function `_postgis_pgsql_version`
we are doing the same pattern matching (`PostgreSQL ([0-9\.]+)`).
I think we s
On Mon, Jan 14, 2019 at 5:48 PM Raúl Marín Rodríguez
wrote:
> > I don't think we have faced this issue with upgrade in the past...
>
> Before PG11, Postgis didn't need to check the Postgresql release at runtime
> in the SQL code. As a reference, in the function `_postgis_pgsql_version`
> we are d
I've created https://trac.osgeo.org/postgis/ticket/4296
--
Raúl Marín Rodríguez
carto.com
___
postgis-users mailing list
postgis-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users
As others said, indexing time is proportional to table size (actually more
like O( N logN )). So if the number of rows is reduced the index build
time will decrease.
In a recent blog post Paul listed some ideas about how index build
performance could be improved via parallelization [1]. But tha
I went back over my efforts to gather all of the Washington State counties
road networks into PostGIS. I was mistaken when I said the problem was in
shapefiles, it turns out I'm seeing multicurves in FileGDB. I apologize for
reporting the problem as a shapefile issue. It's a FileGDB issue.
On to F
Could you not create a table with a generic geometry column without typmodbor
constraints? The tell ogr2ogr not to overwrite the extant table?
Sent from BlueMail
On 15 Jan. 2019, 11:45, at 11:45, Clifford Snow wrote:
>I went back over my efforts to gather all of the Washington State
>countie
On Mon, Jan 14, 2019 at 5:46 PM Simon (SPDBA) Greener <
si...@spatialdbadvisor.com> wrote:
> Could you not create a table with a generic geometry column without
> typmodbor constraints? The tell ogr2ogr not to overwrite the extant table?
>
The overwrite is just to test importing data. I've tested
Have you tried -nlt CONVERT_TO_CURVE ?
On Mon, Jan 14, 2019, 20:47 Clifford Snow
>
> On Mon, Jan 14, 2019 at 5:46 PM Simon (SPDBA) Greener <
> si...@spatialdbadvisor.com> wrote:
>
>> Could you not create a table with a generic geometry column without
>> typmodbor constraints? The tell ogr2ogr not
On Mon, Jan 14, 2019 at 7:45 PM James Klassen wrote:
> Have you tried -nlt CONVERT_TO_CURVE ?
>
I hadn't considered converting to curve. The data set contains 146970
linestrings total. 2,329 of those are multicurve. Skipping failures could
give two tables, one multilinestring and one multicurve.
20 matches
Mail list logo
