On 10/13/2005 09:38:36 AM, Bruce Momjian wrote:

> > Fair enough. At the same time it sure would be nice if
> > plpgsql actually compiled (and parsed SQL) at
> > function definition time, even when the result is thrown away.
> > I'm building a big system and it's quite annoying
> > to get syntax errors, IIRC,
> > in code months after writing it, just because it took
> > me that long to get around to exercising a particular
> > IF statement.
>
> 8.0 has this improvement:
>
> * Do minimal syntax checking of PL/pgSQL functions at creation
> time (Tom)
> This allows us to catch simple syntax errors sooner.
>
> I assume you are running an earlier version of PostgreSQL.

I was, but switched to 8.0.2 and then 8.0.3 as soon as it came out.

Perhaps my problems are more to do with not-simple syntax errors,
or I could be recalling my experience before 8.0.x. I definately
do not recall catching any additional errors at compile time as
part of the switch to 8. Call it paranoia, I'm still not
confident. More compile time checks are better!
Gimmie!
Mine!
*Ahem*...

Ok. Thanks for the reply. I'm done with the bulk of the code
at this point but I'll keep a lookout for cases where
syntax/datatype errors crop up out of the blue.

Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Thu, Oct 13, 2005 at 03:51:15PM +0000, Karl O. Pinc wrote:
> I definately do not recall catching any additional errors at
> compile time as part of the switch to 8.

8.0's syntax checking is minimal; 8.1's will be better. Also, you
might not even have plpgsql's lanvalidator function if you restored
from an earlier version. What's the result of the following query?

SELECT * FROM pg_language WHERE lanname = 'plpgsql';

If lanvalidator is 0 then you won't get even the minimal syntax
checks. 8.1 will avoid this problem by creating languages based
on entries in a template table (pg_pltemplate).

--
Michael Fuhr

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Thu, Oct 13, 2005 at 04:24:23PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > On Thu, Oct 13, 2005 at 01:30:56PM -0400, Tom Lane wrote:
> >> Basically, DECLARE introduces a new name scope that wouldn't be there
> >> if you didn't say DECLARE. Without some bizarre reinterpretation of the
> >> meaning of a DECLARE at the start of a function, variables automatically
> >> created by plpgsql are going to be in an outer scope surrounding that of
> >> the first DECLARE.
>
> > Another possibility is tracking what level sub-block something is in,
> > and using that to determine if the top-most declare in a function is
> > over-writing something.
>
> BTW, another issue here is that if we did merge the first DECLARE with
> the scope of auto-declared variables, it would be a non backwards
> compatible change. Right now you can do, say,

I wasn't suggesting that we actually merge the scopes; is it possible to
detect over-writing a variable without merging them?

> declare found int;
>
> and it'll override the standard FOUND variable. If we change this then
> you'd get an error. (Of course, it could be argued that that would be
> a Good Thing. But it would inhibit us from adding new auto-declared
> variables that are less central to the language than FOUND, because of
> the risk of breaking existing code.)

I thought we were only talking about throwing a warning, not an error. I
don't think it makes sense to throw an error for any of these cases,
because it could well be what the user wants, but it would be nice to
warn them since there's a good chance it's a mistake (especially in the
top-level).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On 10/14/2005 09:30:51 AM, Michael Fuhr wrote:
>> On Thu, Oct 13, 2005 at 03:51:15PM +0000, Karl O. Pinc wrote:
> > I definately do not recall catching any additional errors at
> > compile time as part of the switch to 8.

> 8.0's syntax checking is minimal; 8.1's will be better.

Looking forward to it!

Also, you
> might not even have plpgsql's lanvalidator function if you restored
> from an earlier version. What's the result of the following query?
>
> SELECT * FROM pg_language WHERE lanname = 'plpgsql';
>
> If lanvalidator is 0 then you won't get even the minimal syntax
> checks. 8.1 will avoid this problem by creating languages based
> on entries in a template table (pg_pltemplate).

babase=# SELECT * FROM pg_language WHERE lanname = 'plpgsql';
lanname | lanispl | lanpltrusted | lanplcallfoid | lanvalidator |
lanacl
---------+---------+--------------+---------------+--------------+--------
plpgsql | t | t | 17239 | 17240 |
(1 row)

So I've got it.

IIRC I didn't have anything but test data at the time I upgraded
to 8.0 and so re-created all my databases.

Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Thu, 13 Oct 2005 16:24:23 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> BTW, another issue here is that if we did merge the first DECLARE with
> the scope of auto-declared variables, it would be a non backwards
> compatible change. Right now you can do, say,
>
> declare found int;
>
> and it'll override the standard FOUND variable. If we change this then
> you'd get an error. (Of course, it could be argued that that would be
> a Good Thing. But it would inhibit us from adding new auto-declared
> variables that are less central to the language than FOUND, because of
> the risk of breaking existing code.)

Could something be done using alias?

eg
declare x int;
....
declare x alias for outer x


klint.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq