Thread: psql variables fixed (?)
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
Peter Eisentraut wrote:
>
> 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
> (Btw., was somebody mentioning that this cast syntax is non-standard and
> that he wanted to move toward a standard one? Just wondering.)
Yes, I probably mentioned that. But there is a problem in that the
SQL92 standard does not actually define the "type 'string'" syntax for
anything other than date/time types, since those are the only types
other than true strings defined in the standard. So I extended the
standard (in a natural way imho) to include any string-y input.
I'd be a little reluctant to give up the alternate "::" syntax, only
because I'm not sure I trust the standards folks to not stomp on the
alternative at some point in the future. (Sorry about the
double-negative, but it says what I mean :)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
At 03:08 AM 1/15/00 +0000, Thomas Lockhart wrote: >I'd be a little reluctant to give up the alternate "::" syntax, only >because I'm not sure I trust the standards folks to not stomp on the >alternative at some point in the future. (Sorry about the >double-negative, but it says what I mean :) Which begs the question ... does Postgres.org have representation on the standards commitees? Whether or not there's money available for development, I should think minimal funding for participation in the standards committee (i.e. travel and per-diem, maybe not a salary) wouldn't be hard to scare up... - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I'd be a little reluctant to give up the alternate "::" syntax, only
> because I'm not sure I trust the standards folks to not stomp on the
> alternative at some point in the future.
Even more to the point, we now have a substantial pool of user
applications that rely on "::" (I know a lot of my company's
code does, for example). We can't just blow off those users.
Peter's current proposal seems OK to me, with the caveat that we
will have to be *very* circumspect about introducing additional
variables-automatically-defined-by-psql in the future. Every
time we do, we risk breaking existing user scripts, not unlike
what happens when we introduce a new reserved word in the backend
grammar.
Lane's Other Law: the price of success is backwards compatibility.
regards, tom lane
Don Baccus <dhogaza@pacifier.com> writes:
> Which begs the question ... does Postgres.org have representation
> on the standards commitees?
Not that I've heard about --- for that matter, is there any active
SQL standards committee?
> Whether or not there's money available for development, I should
> think minimal funding for participation in the standards committee
> (i.e. travel and per-diem, maybe not a salary) wouldn't be hard to
> scare up...
While I don't know anything about the SQL standards situation, I do know
how this game is played from past work with JPEG. The only effective
participants on the international standards committees are people who
work for corporate research labs of corporations with very deep pockets.
(Or, occasionally, professors with tenure at universities having very
deep pockets.)
JPEG, for example, used to have a regular schedule of three meetings
a year: one in the Americas, one in Europe, one in the Far East. Your
travel budget didn't stretch that far? Tough luck; you were a bystander
not a player. Not to mention that the real players would organize/host
a local meeting every so often --- better be able to budget a couple of
full-time secretaries to handle the details if you want to do that.
I don't think PostgreSQL, Inc is playing in that league, or has any
prospect of doing so soon. Nor would I want to be our representative
if we could do it. The Net has changed the rules about running
large-scale collaborations, but AFAICT the ISO hasn't heard yet.
regards, tom "professional bystander" lane organizer, Independent JPEG Group
On Sat, 15 Jan 2000, Tom Lane wrote:
> I don't think PostgreSQL, Inc is playing in that league, or has any
> prospect of doing so soon.
Things are picking up, and I'd *love* to be able to do stuff like that,
but "not any time soon"...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Tom Lane wrote: > Lane's Other Law: the price of success is backwards compatibility. "And the onlookers breathed a sigh of relief..."
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