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

Jan

--

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

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

> 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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)Yahoo(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)Yahoo(dot)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(at)gmx(dot)net http://funkturm.homeip.net/~peter

Jan Wieck <JanWieck(at)Yahoo(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)Yahoo(dot)com #

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

Jan Wieck <JanWieck(at)Yahoo(dot)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(at)Yahoo(dot)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(at)Yahoo(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)gmx(dot)net http://funkturm.homeip.net/~peter

Thomas Lockhart <lockhart(at)fourpalms(dot)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(at)gmx(dot)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(at)yahoo(dot)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(at)Yahoo(dot)com #

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

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

> 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(at)candle(dot)pha(dot)pa(dot)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 <pgman(at)candle(dot)pha(dot)pa(dot)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

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

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(at)gmx(dot)net http://funkturm.homeip.net/~peter

> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Peter Eisentraut <peter_e(at)gmx(dot)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

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(at)gmx(dot)net

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)Yahoo(dot)com #

Jan Wieck <JanWieck(at)Yahoo(dot)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

Tom Lane wrote:
>
> Jan Wieck <JanWieck(at)Yahoo(dot)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(at)Yahoo(dot)com #

Change it - but just put it in the release notes :)

Chris

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)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
>