← 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_collate.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_collate.c
14
14
 * 1. The output collation of each expression node, or InvalidOid if it
15
15
 * returns a noncollatable data type.  This can also be InvalidOid if the
16
16
 * result type is collatable but the collation is indeterminate.
17
 
 * 2. The collation to be used in executing each function.      InvalidOid means
 
17
 * 2. The collation to be used in executing each function.  InvalidOid means
18
18
 * that there are no collatable inputs or their collation is indeterminate.
19
19
 * This value is only stored in node types that might call collation-using
20
20
 * functions.
21
21
 *
22
22
 * You might think we could get away with storing only one collation per
23
 
 * node, but the two concepts really need to be kept distinct.  Otherwise
 
23
 * node, but the two concepts really need to be kept distinct.  Otherwise
24
24
 * it's too confusing when a function produces a collatable output type but
25
25
 * has no collatable inputs or produces noncollatable output from collatable
26
26
 * inputs.
27
27
 *
28
28
 * Cases with indeterminate collation might result in an error being thrown
29
 
 * at runtime.  If we knew exactly which functions require collation
 
29
 * at runtime.  If we knew exactly which functions require collation
30
30
 * information, we could throw those errors at parse time instead.
31
31
 *
32
32
 * Portions Copyright (c) 1996-2013, PostgreSQL Global Development Group
231
231
 *              Recursive guts of collation processing.
232
232
 *
233
233
 * Nodes with no children (eg, Vars, Consts, Params) must have been marked
234
 
 * when built.  All upper-level nodes are marked here.
 
234
 * when built.  All upper-level nodes are marked here.
235
235
 *
236
236
 * Note: if this is invoked directly on a List, it will attempt to infer a
237
237
 * common collation for all the list members.  In particular, it will throw
431
431
 
432
432
                        /*
433
433
                         * TargetEntry can have only one child, and should bubble that
434
 
                         * state up to its parent.      We can't use the general-case code
 
434
                         * state up to its parent.  We can't use the general-case code
435
435
                         * below because exprType and friends don't work on TargetEntry.
436
436
                         */
437
437
                        collation = loccontext.collation;
446
446
                         * There are some cases where there might not be a failure, for
447
447
                         * example if the planner chooses to use hash aggregation instead
448
448
                         * of sorting for grouping; but it seems better to predictably
449
 
                         * throw an error.      (Compare transformSetOperationTree, which will
 
449
                         * throw an error.  (Compare transformSetOperationTree, which will
450
450
                         * throw error for indeterminate collation of set-op columns, even
451
451
                         * though the planner might be able to implement the set-op
452
452
                         * without sorting.)
484
484
                                 * SubLink.  Act as though the Query returns its first output
485
485
                                 * column, which indeed is what it does for EXPR_SUBLINK and
486
486
                                 * ARRAY_SUBLINK cases.  In the cases where the SubLink
487
 
                                 * returns boolean, this info will be ignored.  Special case:
 
487
                                 * returns boolean, this info will be ignored.  Special case:
488
488
                                 * in EXISTS, the Query might return no columns, in which case
489
489
                                 * we need do nothing.
490
490
                                 *