← Back to branch summary

~ubuntu-branches/ubuntu/trusty/postgresql-9.3/trusty-proposed

« back to all changes in this revision

Viewing changes to src/backend/parser/parse_relation.c

  • Committer: Package Import Robot
  • Author(s): Martin Pitt
  • Date: 2014-07-24 16:13:59 UTC
  • mfrom: (1.1.8)
  • Revision ID: package-import@ubuntu.com-20140724161359-uk325qfv03euxuuh
Tags: 9.3.5-0ubuntu0.14.04.1
https://launchpad.net/bugs/1348176
* New upstream bug fix release: (LP: #1348176)
  - pg_upgrade: Users who upgraded to version 9.3 using pg_upgrade may have
    an issue with transaction information which causes VACUUM to eventually
    fail. These users should run the script provided in the release notes to
    determine if their installation is affected, and then take the remedy
    steps outlined there.
  - Various data integrity and other bug fixes.
  - Secure Unix-domain sockets of temporary postmasters started during make
    check.
    Any local user able to access the socket file could connect as the
    server's bootstrap superuser, then proceed to execute arbitrary code as
    the operating-system user running the test, as we previously noted in
    CVE-2014-0067. This change defends against that risk by placing the
    server's socket in a temporary, mode 0700 subdirectory of /tmp.
  - See release notes for details:
    http://www.postgresql.org/about/news/1534/
* Remove pg_regress patches to support --host=/path, obsolete with above
  upstream changes and not applicable any more.
* Drop tcl8.6 patch, applied upstream.
* Add missing logrotate test dependency.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/backend/parser/parse_relation.c
71
71
 *
72
72
 * A qualified refname (schemaname != NULL) can only match a relation RTE
73
73
 * that (a) has no alias and (b) is for the same relation identified by
74
 
 * schemaname.refname.  In this case we convert schemaname.refname to a
 
74
 * schemaname.refname.  In this case we convert schemaname.refname to a
75
75
 * relation OID and search by relid, rather than by alias name.  This is
76
76
 * peculiar, but it's what SQL says to do.
77
77
 */
181
181
 
182
182
/*
183
183
 * Search the query's table namespace for a relation RTE matching the
184
 
 * given relation OID.  Return the RTE if a unique match, or NULL
 
184
 * given relation OID.  Return the RTE if a unique match, or NULL
185
185
 * if no match.  Raise error if multiple matches.
186
186
 *
187
187
 * See the comments for refnameRangeTblEntry to understand why this
285
285
 *
286
286
 * This is different from refnameRangeTblEntry in that it considers every
287
287
 * entry in the ParseState's rangetable(s), not only those that are currently
288
 
 * visible in the p_namespace list(s).  This behavior is invalid per the SQL
 
288
 * visible in the p_namespace list(s).  This behavior is invalid per the SQL
289
289
 * spec, and it may give ambiguous results (there might be multiple equally
290
290
 * valid matches, but only one will be returned).  This must be used ONLY
291
291
 * as a heuristic in giving suitable error messages.  See errorMissingRTE.
308
308
         * relation.
309
309
         *
310
310
         * NB: It's not critical that RangeVarGetRelid return the correct answer
311
 
         * here in the face of concurrent DDL.  If it doesn't, the worst case
312
 
         * scenario is a less-clear error message.      Also, the tables involved in
 
311
         * here in the face of concurrent DDL.  If it doesn't, the worst case
 
312
         * scenario is a less-clear error message.  Also, the tables involved in
313
313
         * the query are already locked, which reduces the number of cases in
314
314
         * which surprising behavior can occur.  So we do the name lookup
315
315
         * unlocked.
431
431
 
432
432
/*
433
433
 * given an RTE, return RT index (starting with 1) of the entry,
434
 
 * and optionally get its nesting depth (0 = current).  If sublevels_up
 
434
 * and optionally get its nesting depth (0 = current).  If sublevels_up
435
435
 * is NULL, only consider rels at the current nesting level.
436
436
 * Raises error if RTE not found.
437
437
 */
663
663
 *
664
664
 * This is different from colNameToVar in that it considers every entry in
665
665
 * the ParseState's rangetable(s), not only those that are currently visible
666
 
 * in the p_namespace list(s).  This behavior is invalid per the SQL spec,
 
666
 * in the p_namespace list(s).  This behavior is invalid per the SQL spec,
667
667
 * and it may give ambiguous results (there might be multiple equally valid
668
668
 * matches, but only one will be returned).  This must be used ONLY as a
669
669
 * heuristic in giving suitable error messages.  See errorMissingColumn.
1014
1014
 
1015
1015
        /*
1016
1016
         * Get the rel's OID.  This access also ensures that we have an up-to-date
1017
 
         * relcache entry for the rel.  Since this is typically the first access
 
1017
         * relcache entry for the rel.  Since this is typically the first access
1018
1018
         * to a rel in a statement, be careful to get the right access level
1019
1019
         * depending on whether we're doing SELECT FOR UPDATE/SHARE.
1020
1020
         */
2574
2574
 
2575
2575
        /*
2576
2576
         * Check to see if there are any potential matches in the query's
2577
 
         * rangetable.  (Note: cases involving a bad schema name in the RangeVar
 
2577
         * rangetable.  (Note: cases involving a bad schema name in the RangeVar
2578
2578
         * will throw error immediately here.  That seems OK.)
2579
2579
         */
2580
2580
        rte = searchRangeTableForRel(pstate, relation);
2628
2628
        RangeTblEntry *rte;
2629
2629
 
2630
2630
        /*
2631
 
         * If relname was given, just play dumb and report it.  (In practice, a
 
2631
         * If relname was given, just play dumb and report it.  (In practice, a
2632
2632
         * bad qualification name should end up at errorMissingRTE, not here, so
2633
2633
         * no need to work hard on this case.)
2634
2634
         */