From: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
---|---|
To: | Julien Delplanque <julien(dot)delplanque(at)inria(dot)fr>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Questions about PostgreSQL implementation details |
Date: | 2019-12-09 16:31:51 |
Message-ID: | 4d73f680-de1f-8ac2-bb68-8d071faf5248@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-12-09 16:48:35 | Re: ERROR: uncommitted xmin 347341220 from before xid cutoff 967029200 needs to be frozen |
Previous Message | Robert Haas | 2019-12-09 16:21:46 | Re: Online checksums verification in the backend |