1999-02-13 18:22:53 -05:00
|
|
|
/*-------------------------------------------------------------------------
|
1997-11-25 17:07:18 -05:00
|
|
|
*
|
1999-07-18 20:26:20 -04:00
|
|
|
* parse_relation.h
|
|
|
|
|
* prototypes for parse_relation.c.
|
1997-11-25 17:07:18 -05:00
|
|
|
*
|
|
|
|
|
*
|
2020-01-01 12:21:45 -05:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2000-01-26 00:58:53 -05:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1997-11-25 17:07:18 -05:00
|
|
|
*
|
2010-09-20 16:08:53 -04:00
|
|
|
* src/include/parser/parse_relation.h
|
1997-11-25 17:07:18 -05:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
1999-07-18 20:26:20 -04:00
|
|
|
#ifndef PARSE_RELATION_H
|
|
|
|
|
#define PARSE_RELATION_H
|
1997-11-25 17:07:18 -05:00
|
|
|
|
1999-07-15 19:04:24 -04:00
|
|
|
#include "parser/parse_node.h"
|
1997-11-25 17:07:18 -05:00
|
|
|
|
2015-03-11 10:44:04 -04:00
|
|
|
|
2019-12-26 11:16:42 -05:00
|
|
|
extern ParseNamespaceItem *refnameNamespaceItem(ParseState *pstate,
|
|
|
|
|
const char *schemaname,
|
|
|
|
|
const char *refname,
|
|
|
|
|
int location,
|
|
|
|
|
int *sublevels_up);
|
2008-10-05 22:12:56 -04:00
|
|
|
extern CommonTableExpr *scanNameSpaceForCTE(ParseState *pstate,
|
2019-05-22 13:04:48 -04:00
|
|
|
const char *refname,
|
|
|
|
|
Index *ctelevelsup);
|
2017-04-01 00:17:18 -04:00
|
|
|
extern bool scanNameSpaceForENR(ParseState *pstate, const char *refname);
|
2005-06-04 20:38:11 -04:00
|
|
|
extern void checkNameSpaceConflicts(ParseState *pstate, List *namespace1,
|
2019-05-22 13:04:48 -04:00
|
|
|
List *namespace2);
|
2019-12-26 11:16:42 -05:00
|
|
|
extern ParseNamespaceItem *GetNSItemByRangeTablePosn(ParseState *pstate,
|
|
|
|
|
int varno,
|
|
|
|
|
int sublevels_up);
|
2004-04-02 14:07:02 -05:00
|
|
|
extern RangeTblEntry *GetRTEByRangeTablePosn(ParseState *pstate,
|
2019-05-22 13:04:48 -04:00
|
|
|
int varno,
|
|
|
|
|
int sublevels_up);
|
2008-10-06 11:15:22 -04:00
|
|
|
extern CommonTableExpr *GetCTEForRTE(ParseState *pstate, RangeTblEntry *rte,
|
2019-05-22 13:04:48 -04:00
|
|
|
int rtelevelsup);
|
2019-12-26 11:16:42 -05:00
|
|
|
extern Node *scanNSItemForColumn(ParseState *pstate, ParseNamespaceItem *nsitem,
|
|
|
|
|
int sublevels_up, const char *colname,
|
|
|
|
|
int location);
|
2017-10-31 10:34:31 -04:00
|
|
|
extern Node *colNameToVar(ParseState *pstate, const char *colname, bool localonly,
|
2019-05-22 13:04:48 -04:00
|
|
|
int location);
|
2009-01-22 15:16:10 -05:00
|
|
|
extern void markVarForSelectPriv(ParseState *pstate, Var *var,
|
2019-05-22 13:04:48 -04:00
|
|
|
RangeTblEntry *rte);
|
2008-09-01 16:42:46 -04:00
|
|
|
extern Relation parserOpenTable(ParseState *pstate, const RangeVar *relation,
|
2019-05-22 13:04:48 -04:00
|
|
|
int lockmode);
|
Make parser rely more heavily on the ParseNamespaceItem data structure.
When I added the ParseNamespaceItem data structure (in commit 5ebaaa494),
it wasn't very tightly integrated into the parser's APIs. In the wake of
adding p_rtindex to that struct (commit b541e9acc), there is a good reason
to make more use of it: by passing around ParseNamespaceItem pointers
instead of bare RTE pointers, we can get rid of various messy methods for
passing back or deducing the rangetable index of an RTE during parsing.
Hence, refactor the addRangeTableEntryXXX functions to build and return
a ParseNamespaceItem struct, not just the RTE proper; and replace
addRTEtoQuery with addNSItemToQuery, which is passed a ParseNamespaceItem
rather than building one internally.
Also, add per-column data (a ParseNamespaceColumn array) to each
ParseNamespaceItem. These arrays are built during addRangeTableEntryXXX,
where we have column type data at hand so that it's nearly free to fill
the data structure. Later, when we need to build Vars referencing RTEs,
we can use the ParseNamespaceColumn info to avoid the rather expensive
operations done in get_rte_attribute_type() or expandRTE().
get_rte_attribute_type() is indeed dead code now, so I've removed it.
This makes for a useful improvement in parse analysis speed, around 20%
in one moderately-complex test query.
The ParseNamespaceColumn structs also include Var identity information
(varno/varattno). That info isn't actually being used in this patch,
except that p_varno == 0 is a handy test for a dropped column.
A follow-on patch will make more use of it.
Discussion: https://postgr.es/m/2461.1577764221@sss.pgh.pa.us
2020-01-02 11:29:01 -05:00
|
|
|
extern ParseNamespaceItem *addRangeTableEntry(ParseState *pstate,
|
|
|
|
|
RangeVar *relation,
|
|
|
|
|
Alias *alias,
|
|
|
|
|
bool inh,
|
|
|
|
|
bool inFromCl);
|
|
|
|
|
extern ParseNamespaceItem *addRangeTableEntryForRelation(ParseState *pstate,
|
|
|
|
|
Relation rel,
|
|
|
|
|
int lockmode,
|
|
|
|
|
Alias *alias,
|
|
|
|
|
bool inh,
|
|
|
|
|
bool inFromCl);
|
|
|
|
|
extern ParseNamespaceItem *addRangeTableEntryForSubquery(ParseState *pstate,
|
|
|
|
|
Query *subquery,
|
|
|
|
|
Alias *alias,
|
|
|
|
|
bool lateral,
|
|
|
|
|
bool inFromCl);
|
|
|
|
|
extern ParseNamespaceItem *addRangeTableEntryForFunction(ParseState *pstate,
|
|
|
|
|
List *funcnames,
|
|
|
|
|
List *funcexprs,
|
|
|
|
|
List *coldeflists,
|
|
|
|
|
RangeFunction *rangefunc,
|
|
|
|
|
bool lateral,
|
|
|
|
|
bool inFromCl);
|
|
|
|
|
extern ParseNamespaceItem *addRangeTableEntryForValues(ParseState *pstate,
|
|
|
|
|
List *exprs,
|
|
|
|
|
List *coltypes,
|
|
|
|
|
List *coltypmods,
|
|
|
|
|
List *colcollations,
|
|
|
|
|
Alias *alias,
|
|
|
|
|
bool lateral,
|
|
|
|
|
bool inFromCl);
|
|
|
|
|
extern ParseNamespaceItem *addRangeTableEntryForTableFunc(ParseState *pstate,
|
|
|
|
|
TableFunc *tf,
|
|
|
|
|
Alias *alias,
|
|
|
|
|
bool lateral,
|
|
|
|
|
bool inFromCl);
|
|
|
|
|
extern ParseNamespaceItem *addRangeTableEntryForJoin(ParseState *pstate,
|
|
|
|
|
List *colnames,
|
|
|
|
|
ParseNamespaceColumn *nscolumns,
|
|
|
|
|
JoinType jointype,
|
Reconsider the representation of join alias Vars.
The core idea of this patch is to make the parser generate join alias
Vars (that is, ones with varno pointing to a JOIN RTE) only when the
alias Var is actually different from any raw join input, that is a type
coercion and/or COALESCE is necessary to generate the join output value.
Otherwise just generate varno/varattno pointing to the relevant join
input column.
In effect, this means that the planner's flatten_join_alias_vars()
transformation is already done in the parser, for all cases except
(a) columns that are merged by JOIN USING and are transformed in the
process, and (b) whole-row join Vars. In principle that would allow
us to skip doing flatten_join_alias_vars() in many more queries than
we do now, but we don't have quite enough infrastructure to know that
we can do so --- in particular there's no cheap way to know whether
there are any whole-row join Vars. I'm not sure if it's worth the
trouble to add a Query-level flag for that, and in any case it seems
like fit material for a separate patch. But even without skipping the
work entirely, this should make flatten_join_alias_vars() faster,
particularly where there are nested joins that it previously had to
flatten recursively.
An essential part of this change is to replace Var nodes'
varnoold/varoattno fields with varnosyn/varattnosyn, which have
considerably more tightly-defined meanings than the old fields: when
they differ from varno/varattno, they identify the Var's position in
an aliased JOIN RTE, and the join alias is what ruleutils.c should
print for the Var. This is necessary because the varno change
destroyed ruleutils.c's ability to find the JOIN RTE from the Var's
varno.
Another way in which this change broke ruleutils.c is that it's no
longer feasible to determine, from a JOIN RTE's joinaliasvars list,
which join columns correspond to which columns of the join's immediate
input relations. (If those are sub-joins, the joinaliasvars entries
may point to columns of their base relations, not the sub-joins.)
But that was a horrid mess requiring a lot of fragile assumptions
already, so let's just bite the bullet and add some more JOIN RTE
fields to make it more straightforward to figure that out. I added
two integer-List fields containing the relevant column numbers from
the left and right input rels, plus a count of how many merged columns
there are.
This patch depends on the ParseNamespaceColumn infrastructure that
I added in commit 5815696bc. The biggest bit of code change is
restructuring transformFromClauseItem's handling of JOINs so that
the ParseNamespaceColumn data is propagated upward correctly.
Other than that and the ruleutils fixes, everything pretty much
just works, though some processing is now inessential. I grabbed
two pieces of low-hanging fruit in that line:
1. In find_expr_references, we don't need to recurse into join alias
Vars anymore. There aren't any except for references to merged USING
columns, which are more properly handled when we scan the join's RTE.
This change actually fixes an edge-case issue: we will now record a
dependency on any type-coercion function present in a USING column's
joinaliasvar, even if that join column has no references in the query
text. The odds of the missing dependency causing a problem seem quite
small: you'd have to posit somebody dropping an implicit cast between
two data types, without removing the types themselves, and then having
a stored rule containing a whole-row Var for a join whose USING merge
depends on that cast. So I don't feel a great need to change this in
the back branches. But in theory this way is more correct.
2. markRTEForSelectPriv and markTargetListOrigin don't need to recurse
into join alias Vars either, because the cases they care about don't
apply to alias Vars for USING columns that are semantically distinct
from the underlying columns. This removes the only case in which
markVarForSelectPriv could be called with NULL for the RTE, so adjust
the comments to describe that hack as being strictly internal to
markRTEForSelectPriv.
catversion bump required due to changes in stored rules.
Discussion: https://postgr.es/m/7115.1577986646@sss.pgh.pa.us
2020-01-09 11:56:59 -05:00
|
|
|
int nummergedcols,
|
Make parser rely more heavily on the ParseNamespaceItem data structure.
When I added the ParseNamespaceItem data structure (in commit 5ebaaa494),
it wasn't very tightly integrated into the parser's APIs. In the wake of
adding p_rtindex to that struct (commit b541e9acc), there is a good reason
to make more use of it: by passing around ParseNamespaceItem pointers
instead of bare RTE pointers, we can get rid of various messy methods for
passing back or deducing the rangetable index of an RTE during parsing.
Hence, refactor the addRangeTableEntryXXX functions to build and return
a ParseNamespaceItem struct, not just the RTE proper; and replace
addRTEtoQuery with addNSItemToQuery, which is passed a ParseNamespaceItem
rather than building one internally.
Also, add per-column data (a ParseNamespaceColumn array) to each
ParseNamespaceItem. These arrays are built during addRangeTableEntryXXX,
where we have column type data at hand so that it's nearly free to fill
the data structure. Later, when we need to build Vars referencing RTEs,
we can use the ParseNamespaceColumn info to avoid the rather expensive
operations done in get_rte_attribute_type() or expandRTE().
get_rte_attribute_type() is indeed dead code now, so I've removed it.
This makes for a useful improvement in parse analysis speed, around 20%
in one moderately-complex test query.
The ParseNamespaceColumn structs also include Var identity information
(varno/varattno). That info isn't actually being used in this patch,
except that p_varno == 0 is a handy test for a dropped column.
A follow-on patch will make more use of it.
Discussion: https://postgr.es/m/2461.1577764221@sss.pgh.pa.us
2020-01-02 11:29:01 -05:00
|
|
|
List *aliasvars,
|
Reconsider the representation of join alias Vars.
The core idea of this patch is to make the parser generate join alias
Vars (that is, ones with varno pointing to a JOIN RTE) only when the
alias Var is actually different from any raw join input, that is a type
coercion and/or COALESCE is necessary to generate the join output value.
Otherwise just generate varno/varattno pointing to the relevant join
input column.
In effect, this means that the planner's flatten_join_alias_vars()
transformation is already done in the parser, for all cases except
(a) columns that are merged by JOIN USING and are transformed in the
process, and (b) whole-row join Vars. In principle that would allow
us to skip doing flatten_join_alias_vars() in many more queries than
we do now, but we don't have quite enough infrastructure to know that
we can do so --- in particular there's no cheap way to know whether
there are any whole-row join Vars. I'm not sure if it's worth the
trouble to add a Query-level flag for that, and in any case it seems
like fit material for a separate patch. But even without skipping the
work entirely, this should make flatten_join_alias_vars() faster,
particularly where there are nested joins that it previously had to
flatten recursively.
An essential part of this change is to replace Var nodes'
varnoold/varoattno fields with varnosyn/varattnosyn, which have
considerably more tightly-defined meanings than the old fields: when
they differ from varno/varattno, they identify the Var's position in
an aliased JOIN RTE, and the join alias is what ruleutils.c should
print for the Var. This is necessary because the varno change
destroyed ruleutils.c's ability to find the JOIN RTE from the Var's
varno.
Another way in which this change broke ruleutils.c is that it's no
longer feasible to determine, from a JOIN RTE's joinaliasvars list,
which join columns correspond to which columns of the join's immediate
input relations. (If those are sub-joins, the joinaliasvars entries
may point to columns of their base relations, not the sub-joins.)
But that was a horrid mess requiring a lot of fragile assumptions
already, so let's just bite the bullet and add some more JOIN RTE
fields to make it more straightforward to figure that out. I added
two integer-List fields containing the relevant column numbers from
the left and right input rels, plus a count of how many merged columns
there are.
This patch depends on the ParseNamespaceColumn infrastructure that
I added in commit 5815696bc. The biggest bit of code change is
restructuring transformFromClauseItem's handling of JOINs so that
the ParseNamespaceColumn data is propagated upward correctly.
Other than that and the ruleutils fixes, everything pretty much
just works, though some processing is now inessential. I grabbed
two pieces of low-hanging fruit in that line:
1. In find_expr_references, we don't need to recurse into join alias
Vars anymore. There aren't any except for references to merged USING
columns, which are more properly handled when we scan the join's RTE.
This change actually fixes an edge-case issue: we will now record a
dependency on any type-coercion function present in a USING column's
joinaliasvar, even if that join column has no references in the query
text. The odds of the missing dependency causing a problem seem quite
small: you'd have to posit somebody dropping an implicit cast between
two data types, without removing the types themselves, and then having
a stored rule containing a whole-row Var for a join whose USING merge
depends on that cast. So I don't feel a great need to change this in
the back branches. But in theory this way is more correct.
2. markRTEForSelectPriv and markTargetListOrigin don't need to recurse
into join alias Vars either, because the cases they care about don't
apply to alias Vars for USING columns that are semantically distinct
from the underlying columns. This removes the only case in which
markVarForSelectPriv could be called with NULL for the RTE, so adjust
the comments to describe that hack as being strictly internal to
markRTEForSelectPriv.
catversion bump required due to changes in stored rules.
Discussion: https://postgr.es/m/7115.1577986646@sss.pgh.pa.us
2020-01-09 11:56:59 -05:00
|
|
|
List *leftcols,
|
|
|
|
|
List *rightcols,
|
2019-05-22 13:04:48 -04:00
|
|
|
Alias *alias,
|
|
|
|
|
bool inFromCl);
|
Make parser rely more heavily on the ParseNamespaceItem data structure.
When I added the ParseNamespaceItem data structure (in commit 5ebaaa494),
it wasn't very tightly integrated into the parser's APIs. In the wake of
adding p_rtindex to that struct (commit b541e9acc), there is a good reason
to make more use of it: by passing around ParseNamespaceItem pointers
instead of bare RTE pointers, we can get rid of various messy methods for
passing back or deducing the rangetable index of an RTE during parsing.
Hence, refactor the addRangeTableEntryXXX functions to build and return
a ParseNamespaceItem struct, not just the RTE proper; and replace
addRTEtoQuery with addNSItemToQuery, which is passed a ParseNamespaceItem
rather than building one internally.
Also, add per-column data (a ParseNamespaceColumn array) to each
ParseNamespaceItem. These arrays are built during addRangeTableEntryXXX,
where we have column type data at hand so that it's nearly free to fill
the data structure. Later, when we need to build Vars referencing RTEs,
we can use the ParseNamespaceColumn info to avoid the rather expensive
operations done in get_rte_attribute_type() or expandRTE().
get_rte_attribute_type() is indeed dead code now, so I've removed it.
This makes for a useful improvement in parse analysis speed, around 20%
in one moderately-complex test query.
The ParseNamespaceColumn structs also include Var identity information
(varno/varattno). That info isn't actually being used in this patch,
except that p_varno == 0 is a handy test for a dropped column.
A follow-on patch will make more use of it.
Discussion: https://postgr.es/m/2461.1577764221@sss.pgh.pa.us
2020-01-02 11:29:01 -05:00
|
|
|
extern ParseNamespaceItem *addRangeTableEntryForCTE(ParseState *pstate,
|
|
|
|
|
CommonTableExpr *cte,
|
|
|
|
|
Index levelsup,
|
|
|
|
|
RangeVar *rv,
|
|
|
|
|
bool inFromCl);
|
|
|
|
|
extern ParseNamespaceItem *addRangeTableEntryForENR(ParseState *pstate,
|
|
|
|
|
RangeVar *rv,
|
|
|
|
|
bool inFromCl);
|
2009-10-27 13:11:18 -04:00
|
|
|
extern bool isLockedRefname(ParseState *pstate, const char *refname);
|
Make parser rely more heavily on the ParseNamespaceItem data structure.
When I added the ParseNamespaceItem data structure (in commit 5ebaaa494),
it wasn't very tightly integrated into the parser's APIs. In the wake of
adding p_rtindex to that struct (commit b541e9acc), there is a good reason
to make more use of it: by passing around ParseNamespaceItem pointers
instead of bare RTE pointers, we can get rid of various messy methods for
passing back or deducing the rangetable index of an RTE during parsing.
Hence, refactor the addRangeTableEntryXXX functions to build and return
a ParseNamespaceItem struct, not just the RTE proper; and replace
addRTEtoQuery with addNSItemToQuery, which is passed a ParseNamespaceItem
rather than building one internally.
Also, add per-column data (a ParseNamespaceColumn array) to each
ParseNamespaceItem. These arrays are built during addRangeTableEntryXXX,
where we have column type data at hand so that it's nearly free to fill
the data structure. Later, when we need to build Vars referencing RTEs,
we can use the ParseNamespaceColumn info to avoid the rather expensive
operations done in get_rte_attribute_type() or expandRTE().
get_rte_attribute_type() is indeed dead code now, so I've removed it.
This makes for a useful improvement in parse analysis speed, around 20%
in one moderately-complex test query.
The ParseNamespaceColumn structs also include Var identity information
(varno/varattno). That info isn't actually being used in this patch,
except that p_varno == 0 is a handy test for a dropped column.
A follow-on patch will make more use of it.
Discussion: https://postgr.es/m/2461.1577764221@sss.pgh.pa.us
2020-01-02 11:29:01 -05:00
|
|
|
extern void addNSItemToQuery(ParseState *pstate, ParseNamespaceItem *nsitem,
|
|
|
|
|
bool addToJoinList,
|
|
|
|
|
bool addToRelNameSpace, bool addToVarNameSpace);
|
2015-03-26 14:03:19 -04:00
|
|
|
extern void errorMissingRTE(ParseState *pstate, RangeVar *relation) pg_attribute_noreturn();
|
2012-08-07 19:02:54 -04:00
|
|
|
extern void errorMissingColumn(ParseState *pstate,
|
2019-05-22 13:04:48 -04:00
|
|
|
const char *relname, const char *colname, int location) pg_attribute_noreturn();
|
2005-06-04 15:19:42 -04:00
|
|
|
extern void expandRTE(RangeTblEntry *rte, int rtindex, int sublevels_up,
|
2019-05-22 13:04:48 -04:00
|
|
|
int location, bool include_dropped,
|
|
|
|
|
List **colnames, List **colvars);
|
Make parser rely more heavily on the ParseNamespaceItem data structure.
When I added the ParseNamespaceItem data structure (in commit 5ebaaa494),
it wasn't very tightly integrated into the parser's APIs. In the wake of
adding p_rtindex to that struct (commit b541e9acc), there is a good reason
to make more use of it: by passing around ParseNamespaceItem pointers
instead of bare RTE pointers, we can get rid of various messy methods for
passing back or deducing the rangetable index of an RTE during parsing.
Hence, refactor the addRangeTableEntryXXX functions to build and return
a ParseNamespaceItem struct, not just the RTE proper; and replace
addRTEtoQuery with addNSItemToQuery, which is passed a ParseNamespaceItem
rather than building one internally.
Also, add per-column data (a ParseNamespaceColumn array) to each
ParseNamespaceItem. These arrays are built during addRangeTableEntryXXX,
where we have column type data at hand so that it's nearly free to fill
the data structure. Later, when we need to build Vars referencing RTEs,
we can use the ParseNamespaceColumn info to avoid the rather expensive
operations done in get_rte_attribute_type() or expandRTE().
get_rte_attribute_type() is indeed dead code now, so I've removed it.
This makes for a useful improvement in parse analysis speed, around 20%
in one moderately-complex test query.
The ParseNamespaceColumn structs also include Var identity information
(varno/varattno). That info isn't actually being used in this patch,
except that p_varno == 0 is a handy test for a dropped column.
A follow-on patch will make more use of it.
Discussion: https://postgr.es/m/2461.1577764221@sss.pgh.pa.us
2020-01-02 11:29:01 -05:00
|
|
|
extern List *expandNSItemVars(ParseNamespaceItem *nsitem,
|
|
|
|
|
int sublevels_up, int location,
|
|
|
|
|
List **colnames);
|
2019-12-26 11:16:42 -05:00
|
|
|
extern List *expandNSItemAttrs(ParseState *pstate, ParseNamespaceItem *nsitem,
|
|
|
|
|
int sublevels_up, int location);
|
2002-08-02 14:15:10 -04:00
|
|
|
extern int attnameAttNum(Relation rd, const char *attname, bool sysColOK);
|
2018-10-16 12:44:43 -04:00
|
|
|
extern const NameData *attnumAttName(Relation rd, int attid);
|
1998-02-25 23:46:47 -05:00
|
|
|
extern Oid attnumTypeId(Relation rd, int attid);
|
2011-04-11 21:32:53 -04:00
|
|
|
extern Oid attnumCollationId(Relation rd, int attid);
|
Clean up the mess around EXPLAIN and materialized views.
Revert the matview-related changes in explain.c's API, as per recent
complaint from Robert Haas. The reason for these appears to have been
principally some ill-considered choices around having intorel_startup do
what ought to be parse-time checking, plus a poor arrangement for passing
it the view parsetree it needs to store into pg_rewrite when creating a
materialized view. Do the latter by having parse analysis stick a copy
into the IntoClause, instead of doing it at runtime. (On the whole,
I seriously question the choice to represent CREATE MATERIALIZED VIEW as a
variant of SELECT INTO/CREATE TABLE AS, because that means injecting even
more complexity into what was already a horrid legacy kluge. However,
I didn't go so far as to rethink that choice ... yet.)
I also moved several error checks into matview parse analysis, and
made the check for external Params in a matview more accurate.
In passing, clean things up a bit more around interpretOidsOption(),
and fix things so that we can use that to force no-oids for views,
sequences, etc, thereby eliminating the need to cons up "oids = false"
options when creating them.
catversion bump due to change in IntoClause. (I wonder though if we
really need readfuncs/outfuncs support for IntoClause anymore.)
2013-04-12 19:25:20 -04:00
|
|
|
extern bool isQueryUsingTempRelation(Query *query);
|
2001-10-28 01:26:15 -05:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 15:18:54 -04:00
|
|
|
#endif /* PARSE_RELATION_H */
|
