Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...
| От | Craig Ringer |
|---|---|
| Тема | Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking... |
| Дата | |
| Msg-id | CAMsr+YEwSPCp79X0Kbz4icaJ3bWmh91OZwtcA5LoXhuHip8O1A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking... (Kang Yuzhe <tiggreen87@gmail.com>) |
| Список | pgsql-hackers |
On 28 Apr. 2017 17:04, "Kang Yuzhe" <tiggreen87@gmail.com> wrote:
Anyway as you said, the rough estimation towards any expertise seems to be in abidance with by The 10,000 Hour Rule. I will strive based on this rule.Complex Code Reading like PG. Fully understanding the science of DBMS Engines: Query Processing, Storage stuff, Transaction Management and so on...Hello Simon,The journey that caused and is causing me a lot of pain is finding my way in PG development.
Start with not top-posting on the mailing list ;)
Given x patch, how do I know the specific PG version it was developed for?For now, would please tell me how to know the exact PG version to which a specific patch was developed?
If it a was created by git format-patch then the base git revision will be shown. This may be a commit from postgres public tree that you can find with 'git branch --contains'.
Otherwise look at the proposed commit message if any, in the patch header. Or the email it was attached to. If all else fails guess based on the date.
В списке pgsql-hackers по дате отправления: