From 927d61eeff78363ea3938c818d07e511ebaf75cf Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sun, 10 Jun 2012 15:20:04 -0400 Subject: Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest. --- src/backend/parser/parse_relation.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'src/backend/parser/parse_relation.c') diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c index 2a26b0af1d8..30b307b191c 100644 --- a/src/backend/parser/parse_relation.c +++ b/src/backend/parser/parse_relation.c @@ -274,10 +274,11 @@ searchRangeTable(ParseState *pstate, RangeVar *relation) * relation. * * NB: It's not critical that RangeVarGetRelid return the correct answer - * here in the face of concurrent DDL. If it doesn't, the worst case - * scenario is a less-clear error message. Also, the tables involved in + * here in the face of concurrent DDL. If it doesn't, the worst case + * scenario is a less-clear error message. Also, the tables involved in * the query are already locked, which reduces the number of cases in - * which surprising behavior can occur. So we do the name lookup unlocked. + * which surprising behavior can occur. So we do the name lookup + * unlocked. */ if (!relation->schemaname) cte = scanNameSpaceForCTE(pstate, refname, &ctelevelsup); -- cgit v1.2.3