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

« back to all changes in this revision

Viewing changes to src/pl/plpgsql/src/pl_comp.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
* 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:
288
288
        MemoryContext func_cxt;
289
289
 
290
290
        /*
291
 
         * Setup the scanner input and error info.      We assume that this function
 
291
         * Setup the scanner input and error info.  We assume that this function
292
292
         * cannot be invoked recursively, so there's no need to save and restore
293
293
         * the static variables used here.
294
294
         */
384
384
                         * needed permanently, so make them in tmp cxt.
385
385
                         *
386
386
                         * We also need to resolve any polymorphic input or output
387
 
                         * argument types.      In validation mode we won't be able to, so we
 
387
                         * argument types.  In validation mode we won't be able to, so we
388
388
                         * arbitrarily assume we are dealing with integers.
389
389
                         */
390
390
                        MemoryContextSwitchTo(compile_tmp_cxt);
467
467
 
468
468
                        /*
469
469
                         * If there's just one OUT parameter, out_param_varno points
470
 
                         * directly to it.      If there's more than one, build a row that
 
470
                         * directly to it.  If there's more than one, build a row that
471
471
                         * holds all of them.
472
472
                         */
473
473
                        if (num_out_args == 1)
806
806
        int                     i;
807
807
 
808
808
        /*
809
 
         * Setup the scanner input and error info.      We assume that this function
 
809
         * Setup the scanner input and error info.  We assume that this function
810
810
         * cannot be invoked recursively, so there's no need to save and restore
811
811
         * the static variables used here.
812
812
         */
1062
1062
 
1063
1063
        /*
1064
1064
         * If we find a record/row variable but can't match a field name, throw
1065
 
         * error if there was no core resolution for the ColumnRef either.      In
 
1065
         * error if there was no core resolution for the ColumnRef either.  In
1066
1066
         * that situation, the reference is inevitably going to fail, and
1067
1067
         * complaining about the record/row variable is likely to be more on-point
1068
1068
         * than the core parser's error message.  (It's too bad we don't have
1256
1256
                                /*
1257
1257
                                 * We should not get here, because a RECFIELD datum should
1258
1258
                                 * have been built at parse time for every possible qualified
1259
 
                                 * reference to fields of this record.  But if we do, handle
 
1259
                                 * reference to fields of this record.  But if we do, handle
1260
1260
                                 * it like field-not-found: throw error or return NULL.
1261
1261
                                 */
1262
1262
                                if (error_if_no_field)
1863
1863
 *
1864
1864
 * The returned struct may be a PLpgSQL_var, PLpgSQL_row, or
1865
1865
 * PLpgSQL_rec depending on the given datatype, and is allocated via
1866
 
 * palloc.      The struct is automatically added to the current datum
 
1866
 * palloc.  The struct is automatically added to the current datum
1867
1867
 * array, and optionally to the current namespace.
1868
1868
 */
1869
1869
PLpgSQL_variable *
2317
2317
 * last call.
2318
2318
 *
2319
2319
 * This is used around a DECLARE section to create a list of the VARs
2320
 
 * that have to be initialized at block entry.  Note that VARs can also
 
2320
 * that have to be initialized at block entry.  Note that VARs can also
2321
2321
 * be created elsewhere than DECLARE, eg by a FOR-loop, but it is then
2322
2322
 * the responsibility of special-purpose code to initialize them.
2323
2323
 * ----------
2474
2474
 * delete_function - clean up as much as possible of a stale function cache
2475
2475
 *
2476
2476
 * We can't release the PLpgSQL_function struct itself, because of the
2477
 
 * possibility that there are fn_extra pointers to it.  We can release
 
2477
 * possibility that there are fn_extra pointers to it.  We can release
2478
2478
 * the subsidiary storage, but only if there are no active evaluations
2479
2479
 * in progress.  Otherwise we'll just leak that storage.  Since the
2480
2480
 * case would only occur if a pg_proc update is detected during a nested