Dollar in identifiers

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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