From: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Return Table in StoredProceure/Function |
Date: | 2019-11-21 09:54:38 |
Message-ID: | f956411c-d3e2-7bc6-f78f-7bba1e3e01a6@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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) that works 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 when migrating 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 Server you are in for very nasty surprises as well.
Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | stan | 2019-11-21 11:55:49 | Re: Isolation of multiple databse instances provided by a single postgres server |
Previous Message | Geoff Winkless | 2019-11-21 09:43:26 | Re: REINDEX VERBOSE unknown option |