I have to agree on the geospatial (GIS) features.
I converted from SQL Server to Postgresql for our extended tracking database. The SS geospatial feature set doesn't seem nearly as robust or complete or perfoirmant as that supplied by PostGIS.
The PostGIS ecosystem of open source / 3rd party tools is also far bigger, for anything to do with mapping. Openstreetmaps.org stores their world dataset on Postgresql / PostGIS, and there a ton of mostly open source-based tools and organizations that work with it or any other PostGIS data to provide a complete GIS solution.
My first sS implementation had me backing out of storing geographic points in the relevant SQL Server datatype as the performance hit during loading was just too big. Doing the same thing in Postgresql / PostGIS is nardly noticeable.
Another feature in Postgres is that you are not restricted to just plpgsql as an internal procedural language.
I am not an expert, but it also seems far easier to create, install and work with major extensions to Postgresql than SQL Server. I found installing the GIS featureset in SS to be a bit of a pain back oin the day..
On Tue, 7 May 2019 at 00:53, Michel Pelletier <pelletier.michel@xxxxxxxxx> wrote:
On Mon, May 6, 2019 at 2:49 PM Adam Brusselback <adambrusselback@xxxxxxxxx> wrote:I think the main "gotcha" when I moved from SQL Server to Postgres was I didn't even realize the amount of in-line t-sql I would use to just get stuff done for ad-hoc analysis. Postgres doesn't have a good way to emulate this. DO blocks cannot return resultsets, so short of creating a function and dropping it, it's not possible to get the same workflow.Just ruminating here, and this has probably already been discussed in the past, but I've always wanted something like a 'SELECT DO [LANGUAGE ...] RETURNS rettype | TABLE (...) $$ RETURN [NEXT | QUERY] ... $$; but haven't had any serious problem with creating/dropping functions like you mentioned.-MichelThe lack of GUI tooling was also a huge "whoa" moment for me, which I still grapple with.
