Re: BUG #7943: plpgsql parsing bug

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15.3.2013. 4:49, Tom Lane wrote:
>
> [ shrug ... ] It's right: _t1 is not a scalar variable. (It has
> the composite type s.)
>
> The reason this is problematic is that writing a composite variable as
> the target of a FOR IN SELECT loop is defined as assigning all the
> columns from the SELECT into fields of the composite variable. Which
> is not what you wanted to have happen there, even if we were to extend
> the definition to allow a mixture of scalar and composite variables in
> the target list.
>
> I'd suggest declaring a record variable and using that as the target.
>
> regards, tom lane
>

I changed my approach, so I can live with current behavior, just wanted to report a bug.

So you are saying that I should use single record for result instead of multiple variables.
Ok, that works.

Another thing that was strange is that when I changed
declare _t1 s; to declare _t1 s[];
parsing passed, but of course it blew up at runtime.

Anyway, thanx for the workaround.
I'll see if it's faster comparing fields using record or as I do it currently.

Regards,
Rikard

- --
Rikard Pavelic
http://www.ngs.hr/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJRQtNTAAoJELBms/fUcNQT+s8IAIbnA1cShN7crCCphwgDZAXh
dqHW9V6m1ALPBBIgfhbjH3gPkj/5K9CC+jAGP1zRbHGunrgVKByiIcT+AoAnmGfB
8A7Vw69Yo6kQfi4hYtsEfAhmkpzn4/ZyY+q8+HwNgnAQytxRLg5rtQ5mJLard14U
rxyaZM2uFHGfAp//pkfzaL7pHGd1DC/MAFLnWftUUfraWXdvJmdjQSrunXDfvpYc
rfDSTTlHptK3esrk7UQnd0W9/GvpXjQNvbvgVEJ3YI0K/sUNit8QbL3DXxxOn64g
F+Pc8pIpFWC0RTC9u85VPmGLoA3MI5pkRMTEMxcIONscDbmZsxk13m0zDT3OdFs=
=VWnW
-----END PGP SIGNATURE-----