Thread: 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
Attachment
On Fri, Aug 1, 2014 at 12:34 AM, Marko Tiikkaja <marko@joh.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@joh.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@joh.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