From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | hackers(at)postgresql(dot)org |
Subject: | Re: psql variables fixed (?) |
Date: | 2000-01-16 17:14:12 |
Message-ID: | Pine.LNX.4.21.0001152315070.386-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-01-16 17:18:31 | Re: [HACKERS] TODO list |
Previous Message | Tom Lane | 2000-01-16 17:01:54 | Re: [HACKERS] SELECT...FOR UPDATE OF class_name |