Fabien COELHO <[EMAIL PROTECTED]> wrote:
>
>
> Dear Josh,
>
> Thanks for you reply at length.
>
> It helps me understand the "raw" about my suggestion.
> Some short comments and joke signs:
>
>
> > Adding == would cause harm in the following three ways:
> > 1) It would impair portability betw
>
> Dear Stephan,
>
> > > For the class I have in mind, there are no corner cases, just concepts and
> > > basic practice. They are not going to be db developers, not even computer
> >
> > So no string comparisons? I know that's a mostly unused corner case and
> > all, but... ;)
>
> They survive
Fabien,
> You're arguing that pg should help its "customers" to leave it easilly,
> what is quite paradoxical! ;-)
If we're going to "embrace and extend", we need more market share first. ;-)
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast
Dear Stephan,
> > For the class I have in mind, there are no corner cases, just concepts and
> > basic practice. They are not going to be db developers, not even computer
>
> So no string comparisons? I know that's a mostly unused corner case and
> all, but... ;)
They survive to the idea that t
On Tue, 13 Apr 2004, Fabien COELHO wrote:
>
> > Your Java students would be lulled into a false sense of understanding
> > out of the belief that == in PostgreSQL would work exactly like == in
> > Java ... when it wouldn't work the same in corner cases.
>
> For the class I have in mind, there are
Dear Josh,
Thanks for you reply at length.
It helps me understand the "raw" about my suggestion.
Some short comments and joke signs:
> Adding == would cause harm in the following three ways:
> 1) It would impair portability between PostgreSQL and other databases that
> support the SQL standard
Fabien,
> I agree that listening is something difficult, for me as for every body.
> Also, listening and talking in another language is not easy.
I can understand that. I'm going to reply at length, here, because there is
a principle behind so many of us rejecting your suggestion, and I'd like
On Mon, 12 Apr 2004, Fabien COELHO wrote:
> > Please see my previous e-mail about the value of international standards
> > for educators.
>
> I read your email. I noticed that you want to educate me as an educator;-)
> I partially agree with your point.
>
> We have two words in French: "education
Dear Josh,
> > Still dreaming.
> And still not listening, I guess.
I agree that listening is something difficult, for me as for every body.
Also, listening and talking in another language is not easy.
> You can create your own, C-like operators any time you want to.
I ***already*** did that.
Fabien,
> With "extended", I could have c-like operators;-) : ! && || == !=
>
> Still dreaming.
And still not listening, I guess.
You can create your own, C-like operators any time you want to. In fact, you
could launch a project on pgFoundry (as soon as it's up) for a package of
C-like o
> But making == a synonym for = is just syntactic sugar,
Sure.
> of no obvious practical benefit that I can see.
I can see a small practical benefit, as I could skip the expression part
of my course just by telling them "same as java". No big deal, I agree.
> I think its alleged utility in tea
Fabien COELHO said:
>
>
> So on the point that the standard must be supported, I perfectly agree.
>
> On the point that anything else should be dropped out: let's do it!
> I'll send a patch to remove all those non portable features in
> postgresql that make users write non portable code... But I'm
Dear Jan,
> > If you want to promote postgreSQL, then it should be good that anything
> > from outside (whether standard or not) can work with postgreSQL, but
> > anything that work in pg may not work outside;-)
>
> I couldn't disagree more. What you are asking for is to do whatever (you
> think)
> > Could we consider a three (or more) way setting, for what to do?
> > Something like:
> >
> > sql_noncompliance_mode = error;
> > sql_noncompliance_mode = warn / notice;
> > sql_noncompliance_mode = ignore;
>
> I think a boolean that turns on warnings would be enough.
Hmmm.
I could think of:
scott.marlowe wrote:
> On Thu, 8 Apr 2004, Bruce Momjian wrote:
>
> > Fabien COELHO wrote:
> > >
> > > > > This would help me, at least, write correct and portable SQL. :)
> > > >
> > > > Added to TODO:
> > > >
> > > > * Add a session mode to warn about non-standard SQL usage
> > >
> > >
On Thu, 8 Apr 2004, Bruce Momjian wrote:
> Fabien COELHO wrote:
> >
> > > > This would help me, at least, write correct and portable SQL. :)
> > >
> > > Added to TODO:
> > >
> > > * Add a session mode to warn about non-standard SQL usage
> >
> > So it seems that having C-like operators would h
Fabien COELHO wrote:
>
> > > This would help me, at least, write correct and portable SQL. :)
> >
> > Added to TODO:
> >
> > * Add a session mode to warn about non-standard SQL usage
>
> So it seems that having C-like operators would hurt a lot;-)
>
> So you want to generate warnings for SER
> > This would help me, at least, write correct and portable SQL. :)
>
> Added to TODO:
>
> * Add a session mode to warn about non-standard SQL usage
So it seems that having C-like operators would hurt a lot;-)
So you want to generate warnings for SERIAL, TEXT and a bunch of other
types, W
El Mié 07 Abr 2004 06:28, Fabien COELHO escribió:
> > > > =? as != is a synonum for <>, it would make sense.
> > >
> > > That was never such a terribly good idea, IMHO.
> >
> > Agreed. Compilers should give errors and not try to work around bad code.
>
> Is it bad code? Not for people who come from
Dennis Bjorklund wrote:
> It would be useful with some flag/variable to set that makes pg
> generate varnings for non standard constructs. Unfortunatly there are
> so many things that are non standard, still using != instead of <>
> could be a usable warning.
This is a valid project; in fact it's
Stephen Frost wrote:
-- Start of PGP signed section.
> * Josh Berkus ([EMAIL PROTECTED]) wrote:
> > Were I teaching a class with a SQL component, using PostgreSQL as a tool, I
> > would be very careful to avoid letting my students use an extensions to SQL;
> > no "!=", no "SELECT DISTINCT ON" and
* Josh Berkus ([EMAIL PROTECTED]) wrote:
> Were I teaching a class with a SQL component, using PostgreSQL as a tool, I
> would be very careful to avoid letting my students use an extensions to SQL;
> no "!=", no "SELECT DISTINCT ON" and no alias references in the GROUP BY
> clause.
I'd really l
Fabien,
> Moreover, there are many SQL flavors around, so whatever the detailed
> syntax I learn them, it won't be the one they will have to face if the
> database they use is different. So why bother?
There are so many Java flavors around, why bother teaching the students syntax
at all? The fl
> There is a special display in my imaginary hall of fame of bad design
> decisions for the use of = and == in C and its blind adoption by C++,
> Java, Perl, etc, along with the associated use of "expr ;" as a statement.
>
> That's my view ;-)
Well, I agree with yout view about the C language des
On Wed, 7 Apr 2004, Fabien COELHO wrote:
>
> > > From my point of view, my students come from a java first course, so they
> > > have to learn again some new syntax and new operators. Small stuff, but
> > > it can help to say "same as java" and go on to new concepts.
> >
> > Don't you want them to
Fabien COELHO wrote:
If you want to promote postgreSQL, then it should be good that anything
from outside (whether standard or not) can work with postgreSQL, but
anything that work in pg may not work outside;-)
I couldn't disagree more. What you are asking for is to do whatever (you
think) gets t
Fabien COELHO wrote:
From my point of view, my students come from a java first course, so they
have to learn again some new syntax and new operators. Small stuff, but
it can help to say "same as java" and go on to new concepts.
Don't you want them to learn SQL?
I want to teach them the
On Wed, 7 Apr 2004, Fabien COELHO wrote:
> From my point of view, my students come from a java first course, so they
> have to learn again some new syntax and new operators. Small stuff, but
> it can help to say "same as java" and go on to new concepts.
Don't you want them to learn SQL?
--
/Den
> > From my point of view, my students come from a java first course, so they
> > have to learn again some new syntax and new operators. Small stuff, but
> > it can help to say "same as java" and go on to new concepts.
>
> Don't you want them to learn SQL?
I want to teach them the concepts: relat
> > Is it bad code? Not for people who come from a C/C++/Java background.
>
> It's not the sql operator.
Yes.
> Every week I meet MySql people that want to port their application to
> another database and run into problems because they use some mysql
> construct instead of the standard sql cons
On Wed, 7 Apr 2004, Fabien COELHO wrote:
> Is it bad code? Not for people who come from a C/C++/Java background.
It's not the sql operator.
Every week I meet MySql people that want to port their application to
another database and run into problems because they use some mysql
construct instead o
> > > =? as != is a synonum for <>, it would make sense.
> >
> > That was never such a terribly good idea, IMHO.
>
> Agreed. Compilers should give errors and not try to work around bad code.
Is it bad code? Not for people who come from a C/C++/Java background.
They are used to operators such as =
On Wed, 7 Apr 2004, Peter Eisentraut wrote:
> > =? as != is a synonum for <>, it would make sense.
>
> That was never such a terribly good idea, IMHO.
Agreed. Compilers should give errors and not try to work around bad code.
Had the first generation of browsers done that we would have had a much
Fabien COELHO wrote:
> Would it hurt anybody if operator == is made a synonym for operator
Yes, people would be induced to write incorrect code.
> =? as != is a synonum for <>, it would make sense.
That was never such a terribly good idea, IMHO. It might have gotten
carried over from PostQUEL.
Dear hackers,
Would it hurt anybody if operator == is made a synonym for operator =?
as != is a synonum for <>, it would make sense.
If it does not hurt, should it be implemented by replicating pg_operator
entries, or would a backend modification be ok? Operator != is NOT in
pg_operator, so it m
35 matches
Mail list logo
