Re: Postgres for SQL Server users

For me, another very useful featureset in Postgres is the extensive set of
datatypes and functions, including the strong JSONB support.

Also, i would focus on the widespread support of Postgresql by services
such as Amazon, Google, Heroku,

Another place to focus on would be the really extensive list of extensions
for datatypes, languages, specialized functions and so on. Things like
PostGIS (already mentioned), PipelineDB and so on, plus Postgres-based
things like Timescale, Citusdata and so on.

On Tue, 7 May 2019 at 07:35, Tony Shelver <tshelver(at)gmail(dot)com> wrote:

> 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.
>>>
>>