Thread: Dollar in identifiers

Dollar in identifiers

From
Jan Wieck
Date:
I'm  not sure if it's according to or violating the standard.   But most other databases allow a '$' inside  of
identifiers.  Well,  most  of  them recommend not to use it, but hey guy's,   what's a recommendation for a
programmer?
   In order to lower porting issues, I think it'd be nice to add   that  to  PostgreSQL  as  well.  It's  two more
charactersin   scan.l and doesn't break the regression test.
 
   Objections?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Re: Dollar in identifiers

From
Bruce Momjian
Date:
>     I'm  not sure if it's according to or violating the standard.
>     But most other databases allow a '$' inside  of  identifiers.
>     Well,  most  of  them recommend not to use it, but hey guy's,
>     what's a recommendation for a programmer?
> 
>     In order to lower porting issues, I think it'd be nice to add
>     that  to  PostgreSQL  as  well.  It's  two more characters in
>     scan.l and doesn't break the regression test.
> 
>     Objections?

Yes.  We would move from standard C identifiers to $ identifiers.  We
have had zero requests for this so I see no need to add it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Dollar in identifiers

From
Jan Wieck
Date:
Bruce Momjian wrote:
> >     I'm  not sure if it's according to or violating the standard.
> >     But most other databases allow a '$' inside  of  identifiers.
> >     Well,  most  of  them recommend not to use it, but hey guy's,
> >     what's a recommendation for a programmer?
> >
> >     In order to lower porting issues, I think it'd be nice to add
> >     that  to  PostgreSQL  as  well.  It's  two more characters in
> >     scan.l and doesn't break the regression test.
> >
> >     Objections?
>
> Yes.  We would move from standard C identifiers to $ identifiers.  We
> have had zero requests for this so I see no need to add it.
   Standard  C?  I  was  talking  about  *allowing*  the  dollar   character in table-, column-, function-names!
   And not all requests show up directly on  the  mailing  lists   any  more.   We'll  see  those  (compatibility)
requesesfrom   Toronto as well pretty soon I guess.
 
   The  thing  is  that  the  dollar  isn't  mentioned  in   the   definition  of  the  <SQL terminal character>
(chapter5.1 of   SQL3) at all. But all DB vendors seem to treat it at least as   <SQL language identifier part>.
 
   Could  you  live  with it when we don't allow a name to start   with a dollar, but allow the dollar inside or at the
end  of   the name?
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Re: Dollar in identifiers

From
Bruce Momjian
Date:
> > >     In order to lower porting issues, I think it'd be nice to add
> > >     that  to  PostgreSQL  as  well.  It's  two more characters in
> > >     scan.l and doesn't break the regression test.
> > >
> > >     Objections?
> >
> > Yes.  We would move from standard C identifiers to $ identifiers.  We
> > have had zero requests for this so I see no need to add it.
> 
>     Standard  C?  I  was  talking  about  *allowing*  the  dollar
>     character in table-, column-, function-names!
> 
>     And not all requests show up directly on  the  mailing  lists
>     any  more.   We'll  see  those  (compatibility) requeses from
>     Toronto as well pretty soon I guess.
> 
>     The  thing  is  that  the  dollar  isn't  mentioned  in   the
>     definition  of  the  <SQL terminal character> (chapter 5.1 of
>     SQL3) at all. But all DB vendors seem to treat it at least as
>     <SQL language identifier part>.
> 
>     Could  you  live  with it when we don't allow a name to start
>     with a dollar, but allow the dollar inside or at the  end  of
>     the name?

We do currently use $1 for params, so allowing dollar in the middle
seems better.  However, I need to see multiple people who need it before
I would say OK.  If we go adding things because _one_ person wants it,
we will end up with a mess.  Someone is working on an
Oracle-compatibility parser.  It would be OK in there.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Dollar in identifiers

From
Jan Wieck
Date:
Bruce Momjian wrote:
> We do currently use $1 for params, so allowing dollar in the middle
> seems better.  However, I need to see multiple people who need it before
> I would say OK.  If we go adding things because _one_ person wants it,
> we will end up with a mess.  Someone is working on an
> Oracle-compatibility parser.  It would be OK in there.
   Exactly  that was my first response in the meeting yesterday.   Put it into the Oracle-compatibility parser when we
have it.   The  question  is  "will  we  for  sure  have that parser and   when?".
 
   But let's see. Is there anybody else out there who would like   this feature? Ian?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Re: Dollar in identifiers

From
Bruce Momjian
Date:
> Bruce Momjian wrote:
> > We do currently use $1 for params, so allowing dollar in the middle
> > seems better.  However, I need to see multiple people who need it before
> > I would say OK.  If we go adding things because _one_ person wants it,
> > we will end up with a mess.  Someone is working on an
> > Oracle-compatibility parser.  It would be OK in there.
> 
>     Exactly  that was my first response in the meeting yesterday.
>     Put it into the Oracle-compatibility parser when we have  it.
>     The  question  is  "will  we  for  sure  have that parser and
>     when?".
> 
>     But let's see. Is there anybody else out there who would like
>     this feature? Ian?

Yes, if you can get other votes for the feature, it has a good chance. 
Seems pretty small.  In fact, you could probably enable it with a
#define that could be safer.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Dollar in identifiers

From
Peter Eisentraut
Date:
Jan Wieck writes:

>     Could  you  live  with it when we don't allow a name to start
>     with a dollar, but allow the dollar inside or at the  end  of
>     the name?

At the end would also be a problem because of parsing conflicts with
operators.  (E.g., foo$<$bar)  I don't really like this idea; we don't
have to follow all the nonsense of other people.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



Re: Dollar in identifiers

From
Ian Lance Taylor
Date:
Jan Wieck <JanWieck@Yahoo.com> writes:

> Bruce Momjian wrote:
> > We do currently use $1 for params, so allowing dollar in the middle
> > seems better.  However, I need to see multiple people who need it before
> > I would say OK.  If we go adding things because _one_ person wants it,
> > we will end up with a mess.  Someone is working on an
> > Oracle-compatibility parser.  It would be OK in there.
> 
>     Exactly  that was my first response in the meeting yesterday.
>     Put it into the Oracle-compatibility parser when we have  it.
>     The  question  is  "will  we  for  sure  have that parser and
>     when?".
> 
>     But let's see. Is there anybody else out there who would like
>     this feature? Ian?

The $ issue isn't one I've run into in practice.  The schemas which
I've seen don't use it.  (Of course, that just means that tomorrow
I'll see one which does use it.)

As you probably know, the Oracle rules on names are:

* 1 to 30 characters long
* must start with an alphabetic character from database character set
* may contain only alphanumeric characters from database character set, or underscore ('_'), dollar sign ('$'), or
poundsign ('#')
 

Even I would not argue that the pound sign should be permitted in
Postgres identifiers.  I do think that permitting dollar signs would
do no harm and might help some people.

As far as the comparison with C identifiers goes, I'll note that many
C compilers permit using a dollar sign in an identifier.  For example,
gcc does:   http://gcc.gnu.org/onlinedocs/gcc-3.0/gcc_5.html#SEC96

Ian


Re: Dollar in identifiers

From
Jan Wieck
Date:
Peter Eisentraut wrote:
> Jan Wieck writes:
>
> >     Could  you  live  with it when we don't allow a name to start
> >     with a dollar, but allow the dollar inside or at the  end  of
> >     the name?
>
> At the end would also be a problem because of parsing conflicts with
> operators.  (E.g., foo$<$bar)  I don't really like this idea; we don't
> have to follow all the nonsense of other people.
   I  allways  found  it bad coding style not to separate things   with whitespaces.  But that's just my opinion.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Re: Dollar in identifiers

From
Bruce Momjian
Date:
> Peter Eisentraut wrote:
> > Jan Wieck writes:
> >
> > >     Could  you  live  with it when we don't allow a name to start
> > >     with a dollar, but allow the dollar inside or at the  end  of
> > >     the name?
> >
> > At the end would also be a problem because of parsing conflicts with
> > operators.  (E.g., foo$<$bar)  I don't really like this idea; we don't
> > have to follow all the nonsense of other people.
> 
>     I  allways  found  it bad coding style not to separate things
>     with whitespaces.  But that's just my opinion.

A bigger issue is how we handle future uses of $.  Because $ is such a
natural Unix use for environment variables and positional parameters, we
may fine a use for it some day.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Dollar in identifiers

From
Tom Lane
Date:
Jan Wieck <JanWieck@Yahoo.com> writes:
>     Could  you  live  with it when we don't allow a name to start
>     with a dollar, but allow the dollar inside or at the  end  of
>     the name?

We had *better* not allow an identifier to start with $ --- or have
you forgotten about parameters?

I tend to agree with Bruce on this; we have not seen any requests for
this so far, and I don't much like the idea of decreasing our compliance
with the standard without strong reason.

I'm also concerned about changing the behavior of the lexer for
parameter identifiers adjacent to keywords.  "select$1from foo"
might be horrible coding style, but who's to promise that there
are no applications out there that emit things like that?
        regards, tom lane


Re: Dollar in identifiers

From
Jan Wieck
Date:
Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
> >     Could  you  live  with it when we don't allow a name to start
> >     with a dollar, but allow the dollar inside or at the  end  of
> >     the name?
>
> We had *better* not allow an identifier to start with $ --- or have
> you forgotten about parameters?
   Interestingly  enough,  allowing  it did no break anything in   the regression test. And even PL/pgSQL functions are
able to   deal with these objects out of the box.
 

> I tend to agree with Bruce on this; we have not seen any requests for
> this so far, and I don't much like the idea of decreasing our compliance
> with the standard without strong reason.
>
> I'm also concerned about changing the behavior of the lexer for
> parameter identifiers adjacent to keywords.  "select$1from foo"
> might be horrible coding style, but who's to promise that there
> are no applications out there that emit things like that?
   Does  *that* work currently? Which application could possibly   emit such a statement. Parameters can only  occur
in server   side queries.  So someone must do that crap over SPI.
 


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Re: Dollar in identifiers

From
Gilles DAROLD
Date:
Hi,

Dollar in identifier is currently working, you just have to doublequote the
identifier.

create table "foo$" (   "foo$" int4
);

select * from "foo$";
select "foo$" from "foo$";

works just fine. Or

create table "$foo" (   "$foo" int4
);

select * from "$foo";
select "$foo" from "$foo";

also works.

Perhaps it may be some problems with pl/pgsql, not tested...





Re: Dollar in identifiers

From
Bruce Momjian
Date:
> Hi,
> 
> Dollar in identifier is currently working, you just have to doublequote the
> identifier.
> 
> create table "foo$" (
>     "foo$" int4
> );


Yes, my guess is that they don't want to double-quote.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Dollar in identifiers

From
Thomas Lockhart
Date:
>     I'm  not sure if it's according to or violating the standard.
>     But most other databases allow a '$' inside  of  identifiers.
...
>     Objections?

Not an objection really, but...

Are dollar signs currently allowed in operators? I'd hate to reduce the
allowed number of characters for operators.
                 - Thomas


Re: Dollar in identifiers

From
Peter Eisentraut
Date:
Thomas Lockhart writes:

> Are dollar signs currently allowed in operators? I'd hate to reduce the
> allowed number of characters for operators.

They are, therefore identifiers couldn't start or end with a dollar in any
case.  However, single "$" operator cannot exist, so foo$bar wouldn't be
ambiguous, but the tendency to confuse it with an operator syntax would
reduce the readability of code greatly, IMO.  However, a $$ operator can
exist, so a construct like foo$$bar would parse completely differently,
leaving you with a big mess.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



Re: Dollar in identifiers

From
Tom Lane
Date:
Thomas Lockhart <lockhart@fourpalms.org> writes:
> Are dollar signs currently allowed in operators?

Not at present.  If they were, you'd have a problem telling whether
"$12" is a parameter identifier or a prefix "$" operator applied to an
integer constant.

However, this is no argument for allowing them into identifiers, since
doing so will equally create lexing ambiguity where there was none
before.
        regards, tom lane


Re: Dollar in identifiers

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Thomas Lockhart writes:
>> Are dollar signs currently allowed in operators? I'd hate to reduce the
>> allowed number of characters for operators.

> They are, therefore identifiers couldn't start or end with a dollar in any
> case.  However, single "$" operator cannot exist, so foo$bar wouldn't be
> ambiguous, but the tendency to confuse it with an operator syntax would
> reduce the readability of code greatly, IMO.  However, a $$ operator can
> exist, so a construct like foo$$bar would parse completely differently,
> leaving you with a big mess.

Wups.  Peter is more nearly correct than my previous message was.
I was misled by

regression=# select 1 $ 2;
ERROR:  parser: parse error at or near "$"

But he's correct that "$" is part of the set of allowed operator
characters:

regression=# select 1 $$ 2;
ERROR:  Unable to identify an operator '$$' for types 'integer' and 'integer'       You will have to retype this query
usingan explicit cast
 

The reason a single $ does not work the same is that scan.l returns it
as itself (because it's in the "self" set), not as an Op.  And gram.y
has no productions that involve '$' as a terminal symbol.

I am inclined to think that we should remove $ from the "self" list in
scan.l, which'd allow a single $ to be lexed as an Op.  (This'd not
break parameters, since $n will still be preferentially lexed as a
"param", being longer than the token that could be formed using Op.)

In any case, this is sufficient reason why we cannot allow $ to be
allowed in identifiers: it will break any extant applications that use $
in user-defined operators.
        regards, tom lane


Re: Dollar in identifiers

From
Jan Wieck
Date:
Tom Lane wrote:
> In any case, this is sufficient reason why we cannot allow $ to be
> allowed in identifiers: it will break any extant applications that use $
> in user-defined operators.
   Than  again we're no better than the other DB's. The standard   excludes $  from  any  character  class.  Oracle
and others   violate the standard by allowing them in identifiers while we   alone violate it by allowing them  in
operators.  Well,  at   least we're different!
 
   I would've expected you, Tom, to suggest removing it from the   operators as well :-)


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com



Re: Dollar in identifiers

From
Tom Lane
Date:
Jan Wieck <JanWieck@yahoo.com> writes:
>     I would've expected you, Tom, to suggest removing it from the
>     operators as well :-)

Well, adding a non-standard extension is one thing.  Doing it by
removing a different non-standard extension brings up backwards
compatibility issues.  In this case, I'm not thrilled about the
potential for breaking applications that have relied on our
long-standing, *documented* behavior.

http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/sql-syntax.html#SQL-SYNTAX-OPERATORS
        regards, tom lane


Re: Dollar in identifiers

From
Tom Lane
Date:
I've been thinking some more about this dollar-sign business.  There
are a couple of points that haven't been made yet.  If you'll allow
me to recap:

It seems like there are two reasonable paths we could take:

1. Keep $ as an operator character.  If we go this way, I think we
should allow a single $ as an operator name too (by removing $ from
the set of "self" characters in scan.l, so that it lexes as an Op).

2. Make $ an identifier character.  Remove it from the set of allowed
operator characters, and instead allow it as second-or-later character
in identifiers.  (It cannot be allowed as first character, else it's
totally ambiguous whether $12 is meant to be a parameter or identifier.)

Option 2 improves Oracle compatibility, at the price of breaking
backwards compatibility for applications that presently use $ as part
of multi-character operator names.  (But does anyone know of any?)

An important thing to think about here is the effects on lexing of
parameter symbols ($digits).  Option 1 does not complicate parameter
lexing; $digits will still be read as a parameter since it's a longer
token than could be formed by taking the $ as an Op.  However, this
option doesn't make things any better either: in particular, we still
have the lexing ambiguity of multicharacter operator vs. parameter.
"x+$12" will be read as x +$ 12, though more likely x + $12 was meant.

With $-as-identifier, it'd no longer be possible for adjacent operators
and parameters to be confused.  Instead we have a new ambiguity with
adjacent parameters and identifiers/keywords.  Presently "select$1from"
is read as SELECT param FROM, but with $-as-identifier it'd be read as
a single identifier.  But the interesting point is that this'd make
parameters work a lot more like identifiers.  People don't expect to
be able to write identifiers adjacent to other identifiers with no
whitespace.  They do expect to be able to write them adjacent to
operators.

In fact, with $-as-identifier we'd have this useful property: given a
lexically-recognizable identifier, substitution of a parameter token
for the identifier does not require insertion of any whitespace to
keep the parameter lexically recognizable.  Some of you will recall
plpgsql bugs associated with the fact that the current lexer behavior
does not have this property.  (The other direction doesn't work 100%,
for example: "select $1from" is lexable, "select foofrom" isn't.  But
that direction is much less interesting in practice.)

In short, $-as-identifier makes the lexer behavior noticeably cleaner
than it is now.

I started out firmly in the "keep $ an operator character" camp.  But
after thinking this through I'm sitting on the fence: both options seem
about equally attractive to me.

Comments?
        regards, tom lane


Re: Dollar in identifiers

From
Bruce Momjian
Date:
> In fact, with $-as-identifier we'd have this useful property: given a
> lexically-recognizable identifier, substitution of a parameter token
> for the identifier does not require insertion of any whitespace to
> keep the parameter lexically recognizable.  Some of you will recall
> plpgsql bugs associated with the fact that the current lexer behavior
> does not have this property.  (The other direction doesn't work 100%,
> for example: "select $1from" is lexable, "select foofrom" isn't.  But
> that direction is much less interesting in practice.)
> 
> In short, $-as-identifier makes the lexer behavior noticeably cleaner
> than it is now.
> 
> I started out firmly in the "keep $ an operator character" camp.  But
> after thinking this through I'm sitting on the fence: both options seem
> about equally attractive to me.

Sure, if you want to remove it from operators, that is fine, but adding
it to identifiers seems weird seeing as only one person wants it and it
isn't standard.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Dollar in identifiers

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Sure, if you want to remove it from operators, that is fine, but adding
> it to identifiers seems weird seeing as only one person wants it and it
> isn't standard.

??  I don't see any value in not using $ for *either* purpose.  That
breaks backwards compatibility for hardly any gain at all.
        regards, tom lane


Re: Dollar in identifiers

From
Bruce Momjian
Date:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Sure, if you want to remove it from operators, that is fine, but adding
> > it to identifiers seems weird seeing as only one person wants it and it
> > isn't standard.
> 
> ??  I don't see any value in not using $ for *either* purpose.  That
> breaks backwards compatibility for hardly any gain at all.

OK, if you think it should be kept for backward compatibility, then go
ahead and keep it, but I see little value in adding it to identifiers
unless it is part of an Oracle-compatibility module or at least an
Oracle-compatibility #define.

How many user-defined $ operators do you think are out there?  I doubt
very many.  I would be surprised to find even one.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Dollar in identifiers

From
Peter Eisentraut
Date:
Tom Lane writes:

> Option 2 improves Oracle compatibility, at the price of breaking
> backwards compatibility for applications that presently use $ as part
> of multi-character operator names.  (But does anyone know of any?)

Hmm, postgresql-7.2devel_petere_privatebranch... :-(

Well, the Euro is already allowed in identifiers, so I rest.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



Re: Dollar in identifiers

From
Bruce Momjian
Date:
> Tom Lane writes:
> 
> > Option 2 improves Oracle compatibility, at the price of breaking
> > backwards compatibility for applications that presently use $ as part
> > of multi-character operator names.  (But does anyone know of any?)
> 
> Hmm, postgresql-7.2devel_petere_privatebranch... :-(
> 
> Well, the Euro is already allowed in identifiers, so I rest.

OK, I will give my idea on this and people can make a decision.  

We have pulled over Oracle specific stuff when they added features to
our existing code.  In this case, we are addinng dollarsign to the
identifiers just for compability.  No one is saying, "Gee, I like to see
dollarsigns in my tablenames, and I can't do that."  They want it only
for compatibility.  

Now, I know we have accepted compatibility stuff when it was easy to do.
It is just that changing the identifiers we accept seems pretty major to
me.  However, if others think it isn't a big deal, I can go along with
it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: Dollar in identifiers

From
Tom Lane
Date:
Quite awhile back, we had a discussion about removing "$" from the set
of allowed characters in operator names, and instead allowing it as a
non-first character in identifiers.  (It'd have to be non-first to avoid
ambiguity with parameter symbols "$nnn".)  See, eg,
http://archives.postgresql.org/pgsql-hackers/2001-08/msg00629.php

That discussion petered out without any definite consensus being
reached, but I think it's time to reconsider the idea.  We're getting
flak about "x<$n" being parsed as "x <$ n" rather than "x < $n" (see
current thread in pgsql-sql).  While this has always been a hazard for
SQL and plpgsql function writers, it is now also a hazard in direct
SQL, if you use PREPAREd queries.  So I think the importance of avoiding
such problems has moved up a notch as of 7.3.

So, I'd like to put that proposal back on the table.  Comments anyone?
        regards, tom lane


Re: Dollar in identifiers

From
Bruce Momjian
Date:
I agree.  I think $ is too special to be mixed in with operators.  It is
just used too frequently for variables.

---------------------------------------------------------------------------

Tom Lane wrote:
> Quite awhile back, we had a discussion about removing "$" from the set
> of allowed characters in operator names, and instead allowing it as a
> non-first character in identifiers.  (It'd have to be non-first to avoid
> ambiguity with parameter symbols "$nnn".)  See, eg,
> http://archives.postgresql.org/pgsql-hackers/2001-08/msg00629.php
> 
> That discussion petered out without any definite consensus being
> reached, but I think it's time to reconsider the idea.  We're getting
> flak about "x<$n" being parsed as "x <$ n" rather than "x < $n" (see
> current thread in pgsql-sql).  While this has always been a hazard for
> SQL and plpgsql function writers, it is now also a hazard in direct
> SQL, if you use PREPAREd queries.  So I think the importance of avoiding
> such problems has moved up a notch as of 7.3.
> 
> So, I'd like to put that proposal back on the table.  Comments anyone?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Dollar in identifiers

From
Peter Eisentraut
Date:
Tom Lane writes:

> Quite awhile back, we had a discussion about removing "$" from the set
> of allowed characters in operator names, and instead allowing it as a
> non-first character in identifiers.

I agree with the first one, but does it have to imply the second?

-- 
Peter Eisentraut   peter_e@gmx.net



Re: Dollar in identifiers

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> Quite awhile back, we had a discussion about removing "$" from the set
>> of allowed characters in operator names, and instead allowing it as a
>> non-first character in identifiers.

> I agree with the first one, but does it have to imply the second?

It does not have to, but then we'd only be using "$" for parameters,
which seems like we're not getting our money's worth out of the
character (pun intended).  Also, the original point of that discussion
was that Oracle allows "$" in identifiers, and people wanted to port
Oracle code without having to rename their stuff.
        regards, tom lane


Re: Dollar in identifiers

From
Bruce Momjian
Date:
Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > Quite awhile back, we had a discussion about removing "$" from the set
> > of allowed characters in operator names, and instead allowing it as a
> > non-first character in identifiers.
> 
> I agree with the first one, but does it have to imply the second?

I believe he wanted the second because Oracle supports it, and some
Oracle apps use that feature.  I think in the old days, before
underscore, Oracle used $ for space (double yuck).

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Dollar in identifiers

From
"Dann Corbit"
Date:
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: Thursday, January 09, 2003 1:55 PM
> To: Peter Eisentraut
> Cc: Tom Lane; Jan Wieck; PostgreSQL HACKERS
> Subject: Re: [HACKERS] Dollar in identifiers
>
>
> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > Quite awhile back, we had a discussion about removing "$"
> from the
> > > set of allowed characters in operator names, and instead
> allowing it
> > > as a non-first character in identifiers.
> >
> > I agree with the first one, but does it have to imply the second?
>
> I believe he wanted the second because Oracle supports it,
> and some Oracle apps use that feature.  I think in the old
> days, before underscore, Oracle used $ for space (double yuck).

There are a few others also that use dollar signs such as DEC Rdb,
Interbase/Firebird, etc. as well.



Re: Dollar in identifiers

From
Jan Wieck
Date:
Bruce Momjian wrote:
> 
> Peter Eisentraut wrote:
> > Tom Lane writes:
> >
> > > Quite awhile back, we had a discussion about removing "$" from the set
> > > of allowed characters in operator names, and instead allowing it as a
> > > non-first character in identifiers.
> >
> > I agree with the first one, but does it have to imply the second?
> 
> I believe he wanted the second because Oracle supports it, and some
> Oracle apps use that feature.  I think in the old days, before
> underscore, Oracle used $ for space (double yuck).

Dollar is not allowed as per SQL spec. And I think Oracle discouraged
people from using it, but used it in their own stuff. Good way to avoid
any possible conflicts and I would've liked our version of it to be pg$
instead of pg_ ... I think that's a bit too much to ask for, is it?

The problem is, discouraged or not, if there's a slot people will stick
something into ... meaning if it accepts a dollar, to hell with vendor
recommendations!


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Re: Dollar in identifiers

From
Tom Lane
Date:
Jan Wieck <JanWieck@Yahoo.com> writes:
> The problem is, discouraged or not, if there's a slot people will stick
> something into ... meaning if it accepts a dollar, to hell with vendor
> recommendations!

I'm confused; are you voting against allowing dollar in identifiers?
I thought it was you that proposed allowing it in the first place ...
        regards, tom lane


Re: Dollar in identifiers

From
"Dann Corbit"
Date:
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Thursday, January 09, 2003 2:27 PM
> To: Jan Wieck
> Cc: Bruce Momjian; Peter Eisentraut; PostgreSQL HACKERS
> Subject: Re: [HACKERS] Dollar in identifiers
>
>
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > The problem is, discouraged or not, if there's a slot people will
> > stick something into ... meaning if it accepts a dollar, to
> hell with
> > vendor recommendations!
>
> I'm confused; are you voting against allowing dollar in
> identifiers? I thought it was you that proposed allowing it
> in the first place ...

Suggestion:
Allow them, but issue a warning on schema creation that uses dollars in
identifiers.

"NOTICE: Dollar signs($) in identifiers are not allowed by ANSI/ISO SQL"

Something like that.


Re: Dollar in identifiers

From
Jan Wieck
Date:
Tom Lane wrote:
> 
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > The problem is, discouraged or not, if there's a slot people will stick
> > something into ... meaning if it accepts a dollar, to hell with vendor
> > recommendations!
> 
> I'm confused; are you voting against allowing dollar in identifiers?
> I thought it was you that proposed allowing it in the first place ...

You are, I don't and I was, indeed.

Remove Dollar from the operators and allow it as non-first identifier
char. Please :-)


Jan


> 
>                         regards, tom lane


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Re: Dollar in identifiers

From
"Christopher Kings-Lynne"
Date:
Change it - but just put it in the release notes :)

Chris

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Tom Lane
> Sent: Friday, 10 January 2003 1:10 AM
> To: Jan Wieck; Peter Eisentraut
> Cc: PostgreSQL HACKERS
> Subject: Re: [HACKERS] Dollar in identifiers 
> 
> 
> Quite awhile back, we had a discussion about removing "$" from the set
> of allowed characters in operator names, and instead allowing it as a
> non-first character in identifiers.  (It'd have to be non-first to avoid
> ambiguity with parameter symbols "$nnn".)  See, eg,
> http://archives.postgresql.org/pgsql-hackers/2001-08/msg00629.php
> 
> That discussion petered out without any definite consensus being
> reached, but I think it's time to reconsider the idea.  We're getting
> flak about "x<$n" being parsed as "x <$ n" rather than "x < $n" (see
> current thread in pgsql-sql).  While this has always been a hazard for
> SQL and plpgsql function writers, it is now also a hazard in direct
> SQL, if you use PREPAREd queries.  So I think the importance of avoiding
> such problems has moved up a notch as of 7.3.
> 
> So, I'd like to put that proposal back on the table.  Comments anyone?
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>