Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
| От | Tom Lane | 
|---|---|
| Тема | Re: [HACKERS] Re: Regress tests reveal *serious* psql bug | 
| Дата | |
| Msg-id | 8978.947658153@sss.pgh.pa.us обсуждение исходный текст  | 
		
| Ответ на | Re: [HACKERS] Re: Regress tests reveal *serious* psql bug (Bruce Momjian <pgman@candle.pha.pa.us>) | 
| Ответы | 
                	
            		Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
            		
            		 | 
		
| Список | pgsql-hackers | 
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think we can live with requiring a variable name to start with an
> alphabetic or underscore.
>     SELECT a[1:2]
> is clear and
>     SELECT a[1:myvar]
> expands to SELECT a[1].
No go --- SELECT a[1:b] where b is a field name is a valid query
currently.
I don't really see exactly what the benefit is of assuming that
:foo should expand to nothing rather than :foo, in the absence
of an actual definition for :foo.  My feeling is that a safe solution
would be (a) psql doesn't do variables at all without an explicitly enabling     command line switch; and (b) if psql
sees:foo where foo is not defined, it spits out an     error message.
 
Accepting undeclared variables went out with Basic and Fortran;
why are we intent on re-inventing a concept that's so obviously
dangerous?
> In fact, I think it should be an error to reference a variable that is
> not defined.  This will catch accidental references too.  If you
> reference a variable that does not exist like :myvar, it passes the
> literal :myvar to the backend.
That's two different answers, not one... but I could live with either
one of them...
        regards, tom lane
		
	В списке pgsql-hackers по дате отправления: