Thread: New notices?
postgres=> select * from t4;
NOTICE: Adding missing FROM-clause entry for table t4
m|n
-+-
...
I updated my current tree and now this message comes out on even
simple queries. Is it supposed to be there? If so, why??
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> postgres=> select * from t4;
> NOTICE: Adding missing FROM-clause entry for table t4
Hoo, boy. I think your change didn't quite work right, Bruce...
regards, tom lane
> Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > > postgres=> select * from t4; > > NOTICE: Adding missing FROM-clause entry for table t4 > > Hoo, boy. I think your change didn't quite work right, Bruce... Do you see it there too? I can't see it here. Let me cvs update. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> postgres=> select * from t4; > NOTICE: Adding missing FROM-clause entry for table t4 > m|n > -+- > ... > > I updated my current tree and now this message comes out on even > simple queries. Is it supposed to be there? If so, why?? Strange. I don't get it: test=> select * from pg_language; lanname |lanispl|lanpltrusted|lanplcallfoid|lancompiler --------+-------+------------+-------------+-------------- internal|f |f | 0|n/a lisp |f |f | 0|/usr/ucb/liszt C |f |f | 0|/bin/cc sql |f |f | 0|postgres (4 rows) -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > I updated my current tree and now this message comes out on even
> > simple queries. Is it supposed to be there? If so, why??
> Strange. I don't get it:
I'll bet it is coming from my using expandAll() to support the new
join syntax, and as a kludge I am feeding it a dummy parse state as a
placeholder. As I try to implement table and column aliases, I'll be
mucking around in all of these areas. It isn't at all clear to me from
the notes or from the checks that there was some specific case this
was intended to catch...
In the meantime, I've bracketed my local copy of the code:
#ifdef EMIT_ANNOYING_MESSAGES elog(NOTICE,"Adding missing FROM-clause entry%s for table %s",
pstate->parentParseState!= NULL ? " in subquery" : "", refname);
#endif
;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > > I updated my current tree and now this message comes out on even
> > > simple queries. Is it supposed to be there? If so, why??
> > Strange. I don't get it:
>
> I'll bet it is coming from my using expandAll() to support the new
> join syntax, and as a kludge I am feeding it a dummy parse state as a
> placeholder. As I try to implement table and column aliases, I'll be
> mucking around in all of these areas. It isn't at all clear to me from
> the notes or from the checks that there was some specific case this
> was intended to catch...
This was added to address the long-standing error reports of problems
when addressing aliased and non-aliased columns in the same query. We
don't issue an error, but go ahead and auto-create a from entry, very
non-standard SQL:
SELECT tab.* FROM tab t
Tom Lane and I agreed we need to issue a NOTICE for this type of
auto-FROM creation.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> This was added to address the long-standing error reports of problems
> when addressing aliased and non-aliased columns in the same query. We
> don't issue an error, but go ahead and auto-create a from entry, very
> non-standard SQL:
> SELECT tab.* FROM tab t
> Tom Lane and I agreed we need to issue a NOTICE for this type of
> auto-FROM creation.
OK, but I may happily break it when implementing table and column
aliases for join syntax. Don't know yet what the ramifications will
be...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Tom Lane and I agreed we need to issue a NOTICE for this type of
>> auto-FROM creation.
> OK, but I may happily break it when implementing table and column
> aliases for join syntax. Don't know yet what the ramifications will
> be...
Well, it's certainly a second-order feature. How about you leave the
message turned off until the dust has settled from JOIN, and then we
can see what it takes to make it work right...
regards, tom lane
> Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > >> Tom Lane and I agreed we need to issue a NOTICE for this type of > >> auto-FROM creation. > > > OK, but I may happily break it when implementing table and column > > aliases for join syntax. Don't know yet what the ramifications will > > be... > > Well, it's certainly a second-order feature. How about you leave the > message turned off until the dust has settled from JOIN, and then we > can see what it takes to make it work right... Yes, I think that's the plan. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026