Silly me. The correct behaviour is of course
=> \set foo 3
=> select arr.a[2: :foo];
=> \set bar timestamp
=> select 'now':: :bar;
That way typecasts should bear no compatibility problems.
On 2000-01-14, I mentioned:
> I resolved the issue psql variables vs array syntax in the manner
> suggested by various people. If the variable is undefined the string will
> be untouched. Now something else I'd like to get your comment on is that I
> handled the cast operator '::' in the same way, namely so that
>
> => select 'now'::datetime
> will resolve to
> => select 'now':<value of variable "datetime" if defined>
>
> The reason is that otherwise a construct like this
> => \set foo 3
> => select arr.a[2::foo];
> or even
> => \set foo 'int4'
> => select x:::foo from y;
> won't be possible without introducing an extra syntax trick. And it makes
> it consistent throughout.
>
> (Btw., was somebody mentioning that this cast syntax is non-standard and
> that he wanted to move toward a standard one? Just wondering.)
>
> However, psql defines some variables by itself, for example the one
> containing the last oid. I set up the rule that those variables are always
> all upper-case. If something still fails you can always call \unset VAR to
> unset it before a query. The list of these variables is in the docs.
>
>
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden