Re: Postgres for SQL Server users

From: Tony Shelver <tshelver(at)gmail(dot)com>
To:
Cc: pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Postgres for SQL Server users
Date: 2019-05-07 05:35:26
Message-ID: CAG0dhZCrjc9PEH8oM0KPF8dgsyJBZuVwP_He9j9+5rSde4HXwA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(dot)michel(at)gmail(dot)com>
wrote:

> On Mon, May 6, 2019 at 2:49 PM Adam Brusselback <adambrusselback(at)gmail(dot)com>
> 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.
>
> -Michel
>
>
>> The lack of GUI tooling was also a huge "whoa" moment for me, which I
>> still grapple with.
>>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Igal Sapir 2019-05-07 05:49:12 Re: Postgres for SQL Server users
Previous Message Steven Schlansker 2019-05-07 01:26:17 Re: Computed index on transformation of jsonb key set