Re: Questions about PostgreSQL implementation details

On 12/9/19 7:52 AM, Mark Dilger wrote:
>>
>> Q1.1 If it is possible, is what is done in reality? I have the feeling 
>> that it is not the case and that DDL queries are implemented in C 
>> directly.
> 
> See src/backend/commands/tablecmds.c, function DefineRelation.

I realize I could be a bit more helpful, here.  For a SQL command
like "CREATE TABLE", you can first look in src/backend/parser/gram.y
for the grammar rule.  In this case, searching for CREATE TABLE
leads you to a banner comment around line 3132.  The rule for
CreateStmt creates a node of type CreateStmt.  That leads you
to a struct of the same name in src/include/nodes/parsenodes.h.
You can see all the fields of that struct, and reconcile those
against what the code in gram.y is doing to populate those
fields.  You can then look in src/backend/tcop/utility.c for
the T_CreateStmt nodeTag, and you'll find that it appears in
a few switch statements.  One of those in ProcessUtilitySlow
calls DefineRelation along with a bunch of other stuff.

That's how you can trace these commands.  Let's take DROP TABLE
as a second example.  This one is harder, because "DROP TABLE"
doesn't exist exactly.  It's part of a larger grammar production
for DropStmt that includes other DROP commands.  All the same,
you can see there is a rule for DropStmt that creates a node of
type DropStmt.  Looking in src/include/nodes/parsenodes.h you
can see the struct of the same name.  Looking in tcop/utility.c
you see T_DropStmt is handled in a few switch statements, and
seem to run through ProcessUtilitySlow and ExecDropStmt.  The
function ExecDropStmt has a switch over stmt->removeType, which
was populated back in gram.y to the value OBJECT_TABLE.  That
now serves to select the RemoveRelations function.

This sort of analysis is fairly useful for getting from a SQL
statement to the code in src/backend/commands/ that implements
the guts of that statement.

I hope this helps.

-- 
Mark Dilger