Re: psql variables fixed (?)
От | Peter Eisentraut |
---|---|
Тема | Re: psql variables fixed (?) |
Дата | |
Msg-id | Pine.LNX.4.21.0001152315070.386-100000@localhost.localdomain обсуждение исходный текст |
Ответ на | psql variables fixed (?) (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: