Re: [HACKERS] Packages: Again
| От | Pavel Stehule |
|---|---|
| Тема | Re: [HACKERS] Packages: Again |
| Дата | |
| Msg-id | CAFj8pRBVb5kNLK8cAa7Q5YOs=oE9SdrPige+i2DOa=fSQNMbQQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | [HACKERS] Packages: Again ("Joshua D. Drake" <jd@commandprompt.com>) |
| Ответы |
Re: [HACKERS] Packages: Again
(Fabien COELHO <coelho@cri.ensmp.fr>)
Re: [HACKERS] Packages: Again ("Joshua D. Drake" <jd@commandprompt.com>) Re: [HACKERS] Packages: Again (Gilles Darold <gilles.darold@dalibo.com>) Re: [HACKERS] Packages: Again (Bruce Momjian <bruce@momjian.us>) |
| Список | pgsql-hackers |
2017-01-11 19:57 GMT+01:00 Joshua D. Drake <jd@commandprompt.com>:
-hackers,
I know we have talked about this before but today it was impressed upon me rather firmly. I presented a Webinar: Postgres for Oracle People. The attendees were 90% pl/pgsql developers. 330 people registered for an event that was only allowed to host 100 people. The webinar went on for 2 hours. (it was only scheduled for one hour, that is how interactive it was)
By far the tagline of this webinar from attendees was, "We can not port without packages"
So this is a reality. If we want tried and true Oracle developers to port to PostgreSQL, we must provide some level of package capability.
There are some that would say we don't need them. You are right, we don't need them. We should however want them if we want to continue to stomp through the business sector and continue growth.
We have a schemas instead - the PostgreSQL schema is close to Oracle packages.
What we cannot to substitute are package variables, now - see my proposal for session variables.
Now I am working on migration some large Oracle project - I see more significant issues
1. no good tools - ora2pg do lot of work, but the PL/SQL -> PL/pgSQL migration support is basic
2. some things in Postgres are different - boolean type, enum types, date type, OUT parameters ..
3. some things are really different - NULL versus empty string
4. there are not good tools for postprocessing PL/pgSQL beautifier (formatter), SQL formatter
5. The developers still using Oracle outer joins - there are not 100% automatic migration
6. missing some common patterns for deployment, tests for really big set of code.
Now I work on migration about 500K rows - and it is terrible work. It is 20 years old project - lot of code is not clean, It is hard to migrate, it is hard to clean. Sure, there is not one line of tests.
If we miss some, then it is modern robust tool for migration - big thanks to ora2pg maintainers and developers - without it, there is nothing free.
Regards
Pavel
I use this post to inspire conversation on how we can get this done.
Sincerely,
JD
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: