upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-02-03 20:40:14 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
postgresql/src/backend/parser/README

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

36 lines
1.6 KiB
Text
Raw Permalink Normal View History

Remove cvs keywords from all files.
2010-09-20 16:08:53 -04:00
src/backend/parser/README
Make source code READMEs more consistent. Add CVS tags to all README files.
2008-03-20 13:55:15 -04:00
Parser
More README src cleanups.
2008-03-21 09:23:29 -04:00
======
Make source code READMEs more consistent. Add CVS tags to all README files.
2008-03-20 13:55:15 -04:00
Add README for parser directory
1997-11-26 10:36:00 -05: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-23 18:12:52 -04:00
creates Query structures for the various complex queries that are passed
Add README for parser directory
1997-11-26 10:36:00 -05: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-23 18:12:52 -04:00
scansup.c handle escapes in input strings
Implement parser hooks for processing ColumnRef and ParamRef nodes, as per my recent proposal. As proof of concept, remove knowledge of Params from the core parser, arranging for them to be handled entirely by parser hook functions. It turns out we need an additional hook for that --- I had forgotten about the code that handles inferring a parameter's type from context. This is a preliminary step towards letting plpgsql handle its variables through parser hooks. Additional work remains to be done to expose the facility through SPI, but I think this is all the changes needed in the core parser.
2009-10-30 21:41:31 -04:00
gram.y parse the tokens and produce a "raw" parse tree
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-23 18:12:52 -04:00
analyze.c top level of parse analysis for optimizable queries
Implement parser hooks for processing ColumnRef and ParamRef nodes, as per my recent proposal. As proof of concept, remove knowledge of Params from the core parser, arranging for them to be handled entirely by parser hook functions. It turns out we need an additional hook for that --- I had forgotten about the code that handles inferring a parameter's type from context. This is a preliminary step towards letting plpgsql handle its variables through parser hooks. Additional work remains to be done to expose the facility through SPI, but I think this is all the changes needed in the core parser.
2009-10-30 21:41:31 -04:00
parse_agg.c handle aggregates, like SUM(col1), AVG(col2), ...
Add README for parser directory
1997-11-26 10:36:00 -05:00
parse_clause.c handle clauses like WHERE, ORDER BY, GROUP BY, ...
Small wording improvements for source code READMEs.
2008-04-08 21:00:46 -04:00
parse_coerce.c handle coercing expressions to different data types
Revise collation derivation method and expression-tree representation. All expression nodes now have an explicit output-collation field, unless they are known to only return a noncollatable data type (such as boolean or record). Also, nodes that can invoke collation-aware functions store a separate field that is the collation value to pass to the function. This avoids confusion that arises when a function has collatable inputs and noncollatable output type, or vice versa. Also, replace the parser's on-the-fly collation assignment method with a post-pass over the completed expression tree. This allows us to use a more complex (and hopefully more nearly spec-compliant) assignment rule without paying for it in extra storage in every expression node. Fix assorted bugs in the planner's handling of collations by making collation one of the defining properties of an EquivalenceClass and by converting CollateExprs into discardable RelabelType nodes during expression preprocessing.
2011-03-19 20:29:08 -04:00
parse_collate.c assign collation information in completed expressions
Implement parser hooks for processing ColumnRef and ParamRef nodes, as per my recent proposal. As proof of concept, remove knowledge of Params from the core parser, arranging for them to be handled entirely by parser hook functions. It turns out we need an additional hook for that --- I had forgotten about the code that handles inferring a parameter's type from context. This is a preliminary step towards letting plpgsql handle its variables through parser hooks. Additional work remains to be done to expose the facility through SPI, but I think this is all the changes needed in the core parser.
2009-10-30 21:41:31 -04:00
parse_cte.c handle Common Table Expressions (WITH clauses)
Add README for parser directory
1997-11-26 10:36:00 -05:00
parse_expr.c handle expressions like col, col + 3, x = 3 or x = 4
Update src/backend/parser/README New files have been added to this directory, but not listed here. Repair.
2022-07-22 06:53:12 -04:00
parse_enr.c handle ephemeral named rels (trigger transition tables, ...)
Add Var.varlevelup to code. More parser cleanup.
1998-01-20 17:12:17 -05:00
parse_func.c handle functions, table.column and column identifiers
Update parser README to include parse_jsontable.c The README was missing parse_jsontable.c which handles JSON_TABLE. Oversight in de3600452b61. Author: Karthik S <karthikselvaam@gmail.com> Discussion: https://postgr.es/m/CAK4gQD9gdcj+vq_FZGp=Rv-W+41v8_C7cmCUmDeu=cfrOdfXEw@mail.gmail.com Backpatch-through: 17
2025-09-07 21:07:14 -04:00
parse_jsontable.c handle JSON_TABLE
Update src/backend/parser/README New files have been added to this directory, but not listed here. Repair.
2022-07-22 06:53:12 -04:00
parse_merge.c handle MERGE
Add README for parser directory
1997-11-26 10:36:00 -05:00
parse_node.c create nodes for various structures
Implement parser hooks for processing ColumnRef and ParamRef nodes, as per my recent proposal. As proof of concept, remove knowledge of Params from the core parser, arranging for them to be handled entirely by parser hook functions. It turns out we need an additional hook for that --- I had forgotten about the code that handles inferring a parameter's type from context. This is a preliminary step towards letting plpgsql handle its variables through parser hooks. Additional work remains to be done to expose the facility through SPI, but I think this is all the changes needed in the core parser.
2009-10-30 21:41:31 -04:00
parse_oper.c handle operators in expressions
parse_param.c handle Params (for the cases used in the core backend)
Add README for parser directory
1997-11-26 10:36:00 -05:00
parse_relation.c support routines for tables and column handling
Implement parser hooks for processing ColumnRef and ParamRef nodes, as per my recent proposal. As proof of concept, remove knowledge of Params from the core parser, arranging for them to be handled entirely by parser hook functions. It turns out we need an additional hook for that --- I had forgotten about the code that handles inferring a parameter's type from context. This is a preliminary step towards letting plpgsql handle its variables through parser hooks. Additional work remains to be done to expose the facility through SPI, but I think this is all the changes needed in the core parser.
2009-10-30 21:41:31 -04:00
parse_target.c handle the result list of the query
Small wording improvements for source code READMEs.
2008-04-08 21:00:46 -04: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-23 18:12:52 -04:00
parse_utilcmd.c parse analysis for utility commands (done at execution time)
Move keywords.c/kwlookup.c into src/common/. Now that we have src/common/ for code shared between frontend and backend, we can get rid of (most of) the klugy ways that the keyword table and keyword lookup code were formerly shared between different uses. This is a first step towards a more general plan of getting rid of special-purpose kluges for sharing code in src/bin/. I chose to merge kwlookup.c back into keywords.c, as it once was, and always has been so far as keywords.h is concerned. We could have kept them separate, but there is noplace that uses ScanKeywordLookup without also wanting access to the backend's keyword list, so there seems little point. ecpg is still a bit weird, but at least now the trickiness is documented. I think that the MSVC build script should require no adjustments beyond what's done here ... but we'll soon find out.
2016-03-23 20:22:08 -04:00
See also src/common/keywords.c, which contains the table of standard
keywords and the keyword lookup function. We separated that out because
various frontend code wants to use it too.
Reference in a new issue Copy permalink