Re: Return Table in StoredProceure/Function - Mailing list pgsql-general

From Thomas Kellerer
Subject Re: Return Table in StoredProceure/Function
Date
Msg-id f956411c-d3e2-7bc6-f78f-7bba1e3e01a6@gmx.net
Whole thread Raw
In response to Re: Return Table in StoredProceure/Function  (Tony Shelver <tshelver@gmail.com>)
List pgsql-general
Tony Shelver schrieb am 21.11.2019 um 07:33:
> Well then SQL Server breaks that rule big time :)

I am aware of that - but at the end it's essentially the only DBMS (except for Sybase because of their common roots)
thatworks that way.
 

A migration from SQL Server to Oracle (or MySQL or DB2 or Firebird) would have the same problems.

> Most people coming from a SQL Server background expect procedures to
> return a result set that can be queried, and in-out or out parameters
> to return variables for further information.

One very important aspect of a migration is to also migrate your mindset and the way you solve problems (especially
whenmigrating between two products that behave so differently).
 
The best practices for System A are not always the best practices for System B

Insisting on "But this is the way we did it in System A" is a pretty sure recipe for a failing migration. 

Note that this is true in both directions: if you apply best practices from Postgres or Oracle when migrating _to_ SQL
Serveryou are in for very nasty surprises as well.
 

Thomas






pgsql-general by date:

Previous
From: Geoff Winkless
Date:
Subject: Re: REINDEX VERBOSE iso-8859-1 option
Next
From: stan
Date:
Subject: Re: Isolation of multiple databse instances provided by a singlepostgres server