Re: Stored Procedure warnings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ryan <ryan(at)bel(dot)bc(dot)ca>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Stored Procedure warnings
Date: 2000-07-12 02:01:25
Message-ID: 12020.963367285@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

ryan <ryan(at)bel(dot)bc(dot)ca> writes:
> be=# CREATE FUNCTION freeip ( int4 ) RETURNS inet AS '
> be'# (SELECT ip FROM allips WHERE net = $1)
> be'# EXCEPT
> be'# (SELECT ipaddr FROM ips WHERE ipaddr <<
> be'# (SELECT net FROM nets WHERE netid = $1))
> be'# order by ip'
> be-# LANGUAGE 'sql';
> NOTICE: _outNode: don't know how to print type 703
> NOTICE: _outNode: don't know how to print type 703
> NOTICE: _outNode: don't know how to print type 703
> NOTICE: _outNode: don't know how to print type 703
> CREATE

It's fairly harmless ... I deduce that you are running the postmaster
with some fairly high -d setting, or you wouldn't see it at all.

The underlying problem here is that EXCEPT is implemented in a
bizarre way in which the second SELECT isn't run through the
parse analysis phase right away. If you have parsetree dumping
turned on then the dumper encounters "raw" unanalyzed node types
that it doesn't know how to print. No big deal, really.

We could extend the dumping code to know about more of the raw node
types, but IMHO the real problem is that EXCEPT is done the way it is.
It's on my hit list for 7.2...

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jackson Ching 2000-07-12 05:14:17 Number of Tables
Previous Message Philip Warner 2000-07-12 01:50:51 Re: pg_backup symlink?