Thread

1. Dollar in identifiers

   Jan Wieck <janwieck@yahoo.com> — 2001-08-15T16:56:39Z

       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?
   
   
   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
   
   
   

2. Re: Dollar in identifiers

   Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-15T18:26:06Z

   >     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, Pennsylvania 19026
   
   

3. Re: Dollar in identifiers

   Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-15T19:21:21Z

   > > >     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, Pennsylvania 19026
   
   

4. Re: Dollar in identifiers

   Jan Wieck <janwieck@yahoo.com> — 2001-08-15T19:21:58Z

   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) 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?
   
   
   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
   
   
   

5. Re: Dollar in identifiers

   Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-15T19:37:54Z

   > 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, Pennsylvania 19026
   
   

6. Re: Dollar in identifiers

   Jan Wieck <janwieck@yahoo.com> — 2001-08-15T19:45:39Z

   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
   
   
   

7. Re: Dollar in identifiers

   Peter Eisentraut <peter_e@gmx.net> — 2001-08-15T20:08:25Z

   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
   
   
   

8. Re: Dollar in identifiers

   Ian Lance Taylor <ian@airs.com> — 2001-08-15T20:32:02Z

   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 pound sign ('#')
   
   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
   
   

9. Re: Dollar in identifiers

   Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-15T20:58:31Z

   > 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, Pennsylvania 19026
   
   

10. Re: Dollar in identifiers

    Jan Wieck <janwieck@yahoo.com> — 2001-08-15T21:05:22Z

    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
    
    
    

11. Re: Dollar in identifiers

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-15T21:56:45Z

    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
    
    

12. Re: Dollar in identifiers

    Jan Wieck <janwieck@yahoo.com> — 2001-08-15T22:27:24Z

    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
    
    
    

13. Re: Dollar in identifiers

    Gilles Darold <gilles@darold.net> — 2001-08-16T08:20:46Z

    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...
    
    
    
    
    

14. Re: Dollar in identifiers

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-16T13:31:15Z

    > 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, Pennsylvania 19026
    
    

15. Re: Dollar in identifiers

    lockhart@fourpalms.org — 2001-08-16T15:02:03Z

    >     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
    
    

16. Re: Dollar in identifiers

    Peter Eisentraut <peter_e@gmx.net> — 2001-08-16T16:01:12Z

    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
    
    
    

17. Re: Dollar in identifiers

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-16T17:10:23Z

    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
    
    

18. Re: Dollar in identifiers

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-16T17:28:28Z

    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 using an 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
    
    

19. Re: Dollar in identifiers

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-16T19:12:53Z

    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
    
    

20. Re: Dollar in identifiers

    Jan Wieck <janwieck@yahoo.com> — 2001-08-16T19:12:58Z

    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
    
    
    

21. Re: Dollar in identifiers

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-17T15:00:18Z

    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
    
    

22. Re: Dollar in identifiers

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-17T15:25:10Z

    > 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, Pennsylvania 19026
    
    

23. Re: Dollar in identifiers

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-08-17T15:31:38Z

    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
    
    

24. Re: Dollar in identifiers

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-17T15:34:29Z

    > 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, Pennsylvania 19026
    
    

25. Re: Dollar in identifiers

    Peter Eisentraut <peter_e@gmx.net> — 2001-08-17T15:49:18Z

    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
    
    
    

26. Re: Dollar in identifiers

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-08-17T17:46:27Z

    > 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, Pennsylvania 19026
    
    

27. Re: Dollar in identifiers

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-09T17:09:46Z

    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
    
    

28. Re: Dollar in identifiers

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-01-09T18:14:37Z

    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, Pennsylvania 19073
    
    

29. Re: Dollar in identifiers

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-09T21:48:27Z

    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
    
    

30. Re: Dollar in identifiers

    Peter Eisentraut <peter_e@gmx.net> — 2003-01-09T21:51:01Z

    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
    
    
    

31. Re: Dollar in identifiers

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-01-09T21:55:02Z

    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, Pennsylvania 19073
    
    

32. Re: Dollar in identifiers

    Jan Wieck <janwieck@yahoo.com> — 2003-01-09T22:12:44Z

    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 #
    
    

33. Re: Dollar in identifiers

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-01-09T22:27:28Z

    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
    
    

34. Re: Dollar in identifiers

    Jan Wieck <janwieck@yahoo.com> — 2003-01-09T22:49:55Z

    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 #
    
    

35. Re: Dollar in identifiers

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2003-01-10T01:36:41Z

    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
    >