rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/backend/parser/README

27 lines
1.2 KiB
Plaintext
Raw Normal View History

Small wording improvements for source code READMEs.
2008-04-09 03:00:46 +02:00
$PostgreSQL: pgsql/src/backend/parser/README,v 1.10 2008/04/09 01:00:46 momjian Exp $
Make source code READMEs more consistent. Add CVS tags to all README files.
2008-03-20 18:55:15 +01:00
Parser
More README src cleanups.
2008-03-21 14:23:29 +01:00
======
Make source code READMEs more consistent. Add CVS tags to all README files.
2008-03-20 18:55:15 +01:00
Add README for parser directory
1997-11-26 16:36:00 +01:00
This directory does more than tokenize and parse SQL queries. It also
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
creates Query structures for the various complex queries that are passed
Add README for parser directory
1997-11-26 16:36:00 +01:00
to the optimizer and then executor.
parser.c things start here
scan.l break query into tokens
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
scansup.c handle escapes in input strings
Add README for parser directory
1997-11-26 16:36:00 +01:00
keywords.c turn keywords into specific tokens
gram.y parse the tokens and fill query-type-specific structures
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
analyze.c top level of parse analysis for optimizable queries
Add README for parser directory
1997-11-26 16:36:00 +01:00
parse_clause.c handle clauses like WHERE, ORDER BY, GROUP BY, ...
Small wording improvements for source code READMEs.
2008-04-09 03:00:46 +02:00
parse_coerce.c handle coercing expressions to different data types
Add README for parser directory
1997-11-26 16:36:00 +01:00
parse_expr.c handle expressions like col, col + 3, x = 3 or x = 4
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
parse_oper.c handle operators in expressions
Add README for parser directory
1997-11-26 16:36:00 +01:00
parse_agg.c handle aggregates, like SUM(col1), AVG(col2), ...
Add Var.varlevelup to code. More parser cleanup.
1998-01-20 23:12:17 +01:00
parse_func.c handle functions, table.column and column identifiers
Add README for parser directory
1997-11-26 16:36:00 +01:00
parse_node.c create nodes for various structures
parse_target.c handle the result list of the query
parse_relation.c support routines for tables and column handling
Small wording improvements for source code READMEs.
2008-04-09 03:00:46 +02:00
parse_type.c support routines for data type handling
Separate parse-analysis for utility commands out of parser/analyze.c (which now deals only in optimizable statements), and put that code into a new file parser/parse_utilcmd.c. This helps clarify and enforce the design rule that utility statements shouldn't be processed during the regular parse analysis phase; all interpretation of their meaning should happen after they are given to ProcessUtility to execute. (We need this because we don't retain any locks for a utility statement that's in a plan cache, nor have any way to detect that it's stale.) We are also able to simplify the API for parse_analyze() and related routines, because they will now always return exactly one Query structure. In passing, fix bug #3403 concerning trying to add a serial column to an existing temp table (this is largely Heikki's work, but we needed all that restructuring to make it safe).
2007-06-24 00:12:52 +02:00
parse_utilcmd.c parse analysis for utility commands (done at execution time)