Thanks Kevin for taking your time and justifying the real difficult of
finding ones space/way in PG development.And thanks for your genuine advice
which I have taken it AS IS.
My question is why is that there is a lot of hands-on about PG application
development(eg. connecting to PG using JAVA/JDBC) but almost nothing about
PG hacking hands-on lessons. For example, I wanna add the keyword
"Encrypted" in "CREATE TABLE t1(a int, b int encrypted)" or "CREATE TABLE
t1(a int, b int) encrypted". Alas, its not easy task.

Lastly, I have come to understand that PG community is not harsh to newbies
and thus, I am feeling at home.


On Mon, Apr 17, 2017 at 6:53 PM, Kevin Grittner <> wrote:

> On Tue, Mar 28, 2017 at 10:36 PM, Craig Ringer <>
> wrote:
> > Personally I have to agree that the learning curve is very steep. Some
> > of the docs and presentations help, but there's a LOT to understand.
> Some small patches can be kept to a fairly narrow set of areas, and
> if you can find a similar capability to can crib technique for
> handling some of the more mysterious areas it might brush up
> against.  When I started working on my first *big* patch that was
> bound to touch many areas (around the start of development for 9.1)
> I counted lines of code and found over a million lines just in .c
> and .h files.  We're now closing in on 1.5 million lines.  That's
> not counting over 376,000 lines of documentation in .sgml files,
> over 12,000 lines of text in README* files, over 26,000 lines of
> perl code, over 103,000 lines of .sql code (60% of which is in
> regression tests), over 38,000 lines of .y code (for flex/bison
> parsing), about 9,000 lines of various type of code just for
> generating the configure file, and over 439,000 lines of .po files
> (for message translations).  I'm sure I missed a lot of important
> stuff there, but it gives some idea the challenge it is to get your
> head around it all.
> My first advice is to try to identify which areas of the code you
> will need to touch, and read those over.  Several times.  Try to
> infer the API to areas *that* code needs to reference from looking
> at other code (as similar to what you want to work on as you can
> find), reading code comments and README  files, and asking
> questions.  Secondly, there is a lot that is considered to be
> "coding rules" that is, as far as I've been able to tell, only
> contained inside the heads of veteran PostgreSQL coders, with
> occasional references in the discussion list archives.  Asking
> questions, proposing approaches before coding, and showing work in
> progress early and often will help a lot in terms of discovering
> these issues and allowing you to rearrange things to fit these
> conventions.  If someone with the "gift of gab" is able to capture
> these and put them into a readily available form, that would be
> fantastic.
> > * SSI (haven't gone there yet myself)
> For anyone wanting to approach this area, there is a fair amount to
> look at.  There is some overlap, but in rough order of "practical"
> to "theoretical foundation", you might want to look at:
> The SQL standard
> blob_plain;f=src/backend/storage/lmgr/README-SSI;hb=refs/heads/master
> Papers cited in these last two.  I have found papers authored by
> Alan Fekete or Adul Adya particularly enlightening.
> If any of the other areas that Craig listed have similar work
> available, maybe we should start a Wiki page where we list areas of
> code (starting with the list Craig included) as section headers, and
> put links to useful reading below each?
> --
> Kevin Grittner
> VMware vCenter Server

Reply via email to