Re: [SQL] table aliasing problem with 6.5...
От | Bruce Momjian |
---|---|
Тема | Re: [SQL] table aliasing problem with 6.5... |
Дата | |
Msg-id | 199909281507.LAA18974@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [SQL] table aliasing problem with 6.5... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [SQL] table aliasing problem with 6.5...
|
Список | pgsql-sql |
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> In a situation where you've got subselects, it may not be immediately > >> obvious which FROM list the entry got added to. I can't think of any > >> simple way of identifying that, however :-( > > > Not sure how to handle that either. I could print the subquery level > > number, or I could say "in subquery" or even go fancy and do "in > > sub-sub-query" depending on the number of levels down. > > That seems like a good idea; it won't help tell the difference between > two subqueries at the same level, but in a lot of practical cases it > would tell you what you needed to know, and it won't confuse a novice. > > I like the "... in subquery", "... in sub-subquery", etc wording. > > BTW, Jan was complaining that a number of the regress tests now "fail" > because they provoke this message. Should we just update the expected > outputs, or should we change the tests not to use the feature? I just looked at it, and I woild be required to loop up through the pstate->parentParseState counting how many times I can continue going up, and creating an elog string on the fly to print. Doesn't seem worth it, does it? -- 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
В списке pgsql-sql по дате отправления: