Re: [HACKERS] Re: Regress tests reveal *serious* psql bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: Regress tests reveal *serious* psql bug
Date: 2000-01-12 06:22:33
Message-ID: 8978.947658153@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-01-12 06:33:01 Re: [HACKERS] bug in 6.5.3...
Previous Message Tom Lane 2000-01-12 06:15:00 Re: Regress tests reveal *serious* psql bug