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



Fri, 14 Jan 2000 23:25:36 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
psql variables fixed (?)
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

Sat, 15 Jan 2000 03:08:59 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] psql variables fixed (?)
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 Service and other goodies at
  http://donb.photo.net.

Fri, 14 Jan 2000 20:49:12 -0800
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] psql variables fixed (?)
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

Sat, 15 Jan 2000 00:54:11 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] psql variables fixed (?) 
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

Sat, 15 Jan 2000 01:12:59 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Standards (was Re: psql variables fixed (?))
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 


Sat, 15 Jan 2000 02:27:05 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Standards (was Re: psql variables fixed (?))
Tom Lane wrote:

> Lane's Other Law: the price of success is backwards compatibility.

"And the onlookers breathed a sigh of relief..."




Sat, 15 Jan 2000 10:39:45 -0600
Ed Loehr <eloehr@austin.rr.com>
Re: [HACKERS] psql variables fixed (?)
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



Sun, 16 Jan 2000 18:14:12 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: psql variables fixed (?)