Re: Return Table in StoredProceure/Function
От | Thomas Kellerer |
---|---|
Тема | Re: Return Table in StoredProceure/Function |
Дата | |
Msg-id | f956411c-d3e2-7bc6-f78f-7bba1e3e01a6@gmx.net обсуждение исходный текст |
Ответ на | Re: Return Table in StoredProceure/Function (Tony Shelver <tshelver@gmail.com>) |
Список | 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 по дате отправления: