Message-ID: <44285B78.8010804@gmail.com>
Date: Mon, 27 Mar 2006 23:39:04 +0200
From: Wiebe Cazemier <halfgaar@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20060225)
MIME-Version: 1.0
To: pgsql-sql@postgresql.org
Subject: Re: unique names in variables and columns in plsql functions
References: <4427F7D3.3000103@gmail.com> <14263.1143471744@sss.pgh.pa.us>
In-Reply-To: <14263.1143471744@sss.pgh.pa.us>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigA9FB25B3C3F2A28E5DE866EF"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA9FB25B3C3F2A28E5DE866EF
Content-Type: multipart/mixed;
 boundary="------------010400080206080807010207"

This is a multi-part message in MIME format.
--------------010400080206080807010207
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

(Whoops, pressed wrong reply button. Here it is correctly this time.)

On 03/27/06 17:02, Tom Lane wrote:

>It'll retrieve whatever the current value of the plpgsql variable
>provider_id is.  plpgsql always assumes that ambiguous names refer
>to its variables (indeed, it isn't even directly aware that there's
>any possible ambiguity here).
>  
>
That's why I suspected it would be NULL, since provider_id wasn't
initialised yet.

>
>How and why would it determine that?  In general it's perfectly normal
>to use plpgsql variable values in SQL commands.  I don't think it'd make
>the system more usable if the parser tried to apply a heuristic rule
>about some occurrences being meant as variable references and other ones
>not.  If the rule ever got it wrong, it'd be even more confusing.
>
I guess I'm looking at it too much as a human. I said "SELECT FROM" so,
it guess I assumed it would be clear enough which one it had to use.
But, now that I'm thinking about it some more, I agree. However, a fatal
error would also have been welcome.


--------------010400080206080807010207
Content-Type: application/pgp-signature;
 name="signature.asc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="signature.asc"

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4yLjIg
KEdOVS9MaW51eCkKQ29tbWVudDogVXNpbmcgR251UEcgd2l0aCBUaHVuZGVyYmlyZCAtIGh0
dHA6Ly9lbmlnbWFpbC5tb3pkZXYub3JnCgppRDhEQlFGRUtBTDVNSGtVallvOWQ5QVJBblNB
QUpvREpzK2NPUURkV3FFemxXeXlqeVVUQ2JRMVdRQ2VJS2drCkJxdUJLNHFpNVZVa2VnYVhR
dzV2S3hjPQo9RjkySAotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0KCg==
--------------010400080206080807010207--

--------------enigA9FB25B3C3F2A28E5DE866EF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEKFt4MHkUjYo9d9ARAicLAKC4lCD27Dei2AS74F3TsFq6MgIVLACgq897
mEUg7pwwOjTkyH8jI7jGswM=
=5QJ5
-----END PGP SIGNATURE-----

--------------enigA9FB25B3C3F2A28E5DE866EF--