Change it - but just put it in the release notes :)
Chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane
> Sent: Friday, 10 January 2003 1:10 AM
> To: Jan Wieck; Peter Eisentraut
> Cc: PostgreSQL HACKERS
> Subject: Re
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 firs
Tom Lane wrote:
>
> Jan Wieck <[EMAIL PROTECTED]> 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 identif
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 [EMAIL
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> 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 <[EMA
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 s
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> 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
Jan Wieck <[EMAIL PROTECTED]> 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
Peter Eisentraut <[EMAIL PROTECTED]> 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 t
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 chara
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/pg
> 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... :-(
>
>
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
> Bruce Momjian <[EMAIL PROTECTED]> 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
Bruce Momjian <[EMAIL PROTECTED]> 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 com
> 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 a
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 sing
Jan Wieck <[EMAIL PROTECTED]> 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 cas
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 clas
Peter Eisentraut <[EMAIL PROTECTED]> 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 "$
Thomas Lockhart <[EMAIL PROTECTED]> 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 th
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
ambi
> 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 o
> 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
[EMAIL PROTECTED]
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";
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> 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 forgot
Jan Wieck <[EMAIL PROTECTED]> 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
> 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
> > o
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.,
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 i
> 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
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
> O
> > > 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 $ identifie
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 or
> 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 t
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
36 matches
Mail list logo
