Re: Regress tests reveal *serious* psql bug

Wow that sucks. Shame on me.

On 2000-01-11, Tom Lane mentioned:

> psql converts
>
> SELECT arrtest.a[1:3],
...
> into
...
> SELECT arrtest.a[1],

In some earlier developmental stage I had the variable delimiter runtime
definable since it became clear that the traditional $ wouldn't work.
Later on someone pointed out that the SQL syntax for this is the colon
deal. (And you were in that discussion, if I am not completely off.)
Actually the colon deal only applies to embedded SQL, so ecpg should have
the same problem, but I'm not familiar with it, so I don't know how it
copes.

The fact is that (besides the garden-variety bugs) this is indeed a
problem of definition. I'm not sure if the following is valid by any
standard or even makes sense, but how do you interpret something like
this:

SELECT arrtest.biggest_value_pos, arrtest.a[1:biggest_value_pos] ... ;

There's no way you can disambiguate this unless you redefine everything.

> A minimum requirement is that psql should *not* substitute for :x unless
> x is the name of a psql variable that the user has explicitly defined.

Then psql becomes no better than csh, and that's certainly one of the
worse things one could do.

Putting blame on other people's shoulders I would suggest changing the
array syntax to arr[1][2] like everyone else has, but that would be short
sighted.

The best idea I have to get this working _now_ would be to once again make
the variable delimiter run-time configurable so that you can set it to
: or $ or # or whatever your query doesn't use, completely off by default

If I'm going to hack around in that code, one related question: what
should the deal be regarding variable interpolation into quoted
strings? Yes/No/Maybe?

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden