PL/PgSQL INTO (used to be BUG #8870)

Hi,

As discussed in #8870, the docs make unfounded claims on INTO. Here's a
patch removing the incorrect part.

.marko

On Fri, Aug 1, 2014 at 12:34 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> Here's a patch removing the incorrect part.

I can see how this doc statement can be misunderstood, but I think the
claims are actually about data types, not the number of columns in the
INTO list.

I think clarifying the number of columns quirk would be better than
removing this text.

Regards,
Marti

On 8/1/14 1:33 PM, Marti Raudsepp wrote:
> On Fri, Aug 1, 2014 at 12:34 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
>> Here's a patch removing the incorrect part.
>
> I can see how this doc statement can be misunderstood, but I think the
> claims are actually about data types, not the number of columns in the
> INTO list.

I don't really speak English, but I can't see what else the "as to
number" part could mean.

But the claim about "exactly matching" data types is completely bogus, too:

local:marko=#* do $$ declare _f1 timestamp;
local:marko$#* begin select current_date into _f1;
local:marko$#* end $$ ;
DO

local:marko=# do $$ declare _f1 timestamp;
local:marko$# begin select text '2004-01-01' into _f1;
local:marko$# end $$ ;
DO

.marko

On Fri, Aug 1, 2014 at 2:43 PM, Marko Tiikkaja <marko(at)joh(dot)to> 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