Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XDCPJ-0000RN-41 for pgsql-docs@arkaria.postgresql.org; Fri, 01 Aug 2014 12:58:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XDCPI-00031v-F0 for pgsql-docs@arkaria.postgresql.org; Fri, 01 Aug 2014 12:58:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XDCPH-00031m-Cz for pgsql-docs@postgresql.org; Fri, 01 Aug 2014 12:57:59 +0000 Received: from mail-ie0-x22a.google.com ([2607:f8b0:4001:c03::22a]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XDCPC-0008UJ-E4 for pgsql-docs@postgresql.org; Fri, 01 Aug 2014 12:57:57 +0000 Received: by mail-ie0-f170.google.com with SMTP id rl12so5748216iec.15 for ; Fri, 01 Aug 2014 05:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juffo.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8gkpeld3PdKkk2TzgbWjadB5FZCaxBhQM+DuzS6h6w4=; b=OPRiQ/Pq/1YwndnvsbRrJupOiPk93VQKZJ6GAkkDDGFfIgsCkHq5vyIJbFqvRYXuBY iP7MZuDSGtF1huNjm0XwR4TF0ZtGWuHi6tvWgbWTw8C3L0CzTkl6Y2VML6d/3/CX4JOH iy8Ujo3zKSLTSUZPe4TfUuBvD6khM9jboClOc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8gkpeld3PdKkk2TzgbWjadB5FZCaxBhQM+DuzS6h6w4=; b=dOzFxcDlcuRxXcqeVIwlMLMnF1UEmBNgc0whDCjhJz7C4sV30Fsfg1hP5iSZOOyO0w ZG3CpePSlAzrEWLDs4uw/DXpptvv5CSFIlvrnhxQXg4mQZbF0zHehoDOB3wOM27l02Dp V5cJn311IYYTNcDGzwPEXDbLqW54Go8DzmdWny4mZccMiNn2+zLIHMGbAAJLYSak0DEi jhD+Zl622yjWwN1luto9eIpgctXvIhS+oapP8ABeVA9rRklhDMWPbOXKfRdDtvo5yDFl jjK/QGiiDVF6CBYMzFTZ8z2EbwG/rvOU0TU5fgWCJUf5edVdB7oZRt7Nc7NQGG5M29LE TQQw== X-Gm-Message-State: ALoCoQngGeBsZP47NxXDjBg/r9WC3aYs9s/gkEv1+jt0ZaX2fELRiP8LRJoRRMNN8cJKjpDibRYH X-Received: by 10.42.100.6 with SMTP id y6mr6859783icn.28.1406897871247; Fri, 01 Aug 2014 05:57:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.13.131 with HTTP; Fri, 1 Aug 2014 05:57:10 -0700 (PDT) In-Reply-To: <53DB7D70.4040701@joh.to> References: <53DAB66B.6080405@joh.to> <53DB7D70.4040701@joh.to> From: Marti Raudsepp Date: Fri, 1 Aug 2014 15:57:10 +0300 Message-ID: Subject: Re: PL/PgSQL INTO (used to be BUG #8870) To: Marko Tiikkaja Cc: PG Docs Content-Type: text/plain; charset=UTF-8 X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org On Fri, Aug 1, 2014 at 2:43 PM, Marko Tiikkaja wrote: > But the claim about "exactly matching" data types is completely bogus, too My bad. I remember having a hard time with matching data types in PL/pgSQL in one instance, but turns out that was with RETURN QUERY, not INTO. Anyway, I'd prefer adding an explicit warning about the non-strict behavior. How about: "The number of columns returned by the query is not checked to match target variables. Superfluous target variables are assigned the value NULL. When a record variable is the target, it automatically configures itself to the row type of the query result columns." Regards, Marti -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs