make == as = ?

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.

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
nicer web today.

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.

--
/Dennis Bj�rklund

=? 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 == != % && || !... Some of these
are available from pg, some are not, so at the time it is incoherent.

Also, I would not like == to mean anything but =, as any other meaning
would be quite error prone to users with a C background.

PostgreSQL is really extensible wrt operators, and I'm not that sure
it is so bad an idea to support "C" flavor operators.

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.

You can have two policy. Either you're cool and homogeneous, or either
you're strict. At the time, postgreSQL is rather cool in some place:
!= and <>, ~~ and LIKE... and a little bit inhomogeneous.

--
Fabien.

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 of the standard sql construct. I fail to see it as a
good thing for pg to add more non standard constructs where that standard
works fine. Extensions for things that are hard/impossible to do with
standard sql is a different thing (but should still be done with care).

If people want it I'd rather have them create the operators themself.
That's my view.

--
/Dennis Bj�rklund

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 construct. I fail to see it as a
good thing for pg to add more non standard constructs where that
standard works fine. Extensions for things that are hard/impossible to
do with standard sql is a different thing (but should still be done with
care).

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

This pseudo portability strategy is used by Oracle, IBM, M$ or mysql...
That makes you're clients stay with you longer;-) So usually it is a
success...

semi joke: I was not aware that there is such a thing as an SQL standard.
I have the O'Reilly book about SQL, which declines *every* command for
SQL Server, Oracle, MySQL, PostgreSQL...

If people want it I'd rather have them create the operators themself.

Sure, it is possible to do it so. But if it is in the default
installation, it would help me;-)

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.

Also, if I add some new operators in pg_operator, say && for AND, I'm not
sure the optimiser will know that is a AND and take that into account.

That's my view.

Yep.

--
Fabien Coelho - coelho@cri.ensmp.fr

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?

--
/Dennis Bj�rklund

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: relations, views, relationnal algebra,
aggregation and so on, and how to build a resonnable schema from a
real-world problem.

I do not consider whether the comparison is == or = as a key issue.

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?

That's just my view.

--
Fabien Coelho - coelho@cri.ensmp.fr

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 concepts: relations, views, relationnal algebra,
aggregation and so on, and how to build a resonnable schema from a
real-world problem.

I do not consider whether the comparison is == or = as a key issue.

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?

That's just my view.

My sister is a teacher - she has a bumper sticker that reads
"Monolinguism is curable".

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

cheers

andrew

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 the crowds cheering. That is exactly what MySQL attempts by
stuffing one half baked feature after another into their db product and
calling it "integration". What we try instead is to create a stable,
reliable and predictable database server.

Also, if I add some new operators in pg_operator, say && for AND, I'm not
sure the optimiser will know that is a AND and take that into account.

AND is not an operator, it is a keyword in the first place. And the
optimiser can use a multi-column index containing a user defined data
type here, so it is well aware of the things you add, if you do it right.

Jan

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

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?

I want to teach them the concepts: relations, views, relationnal algebra,
aggregation and so on, and how to build a resonnable schema from a
real-world problem.

Which are all good things. But even if you wanted to make java-like
flavored SQL for such a purpose, I don't see how that ties into changing
the default behavior of postgres flavored SQL.

I do not consider whether the comparison is == or = as a key issue.

It could be if your students think they know SQL and want to get a job
doing it. I know that if I were to ask questions and had someone
consistenly misuse == for = and such it would certainly raise doubts, just
like many answers for a C question about a = a++ + ++a.

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?

Because hopefully by the time your students are out they know how to
generalize their knowledge and be able to use what they've learned as the
base point to learn the various flavors.

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 flavor they work with in your class will probably be different
from what they have on the job.

See my point?

One of the primary reasons for the existence of international standards is
education. If you stick to Beginning & Intermediate SQL92, you can give your
students a set of SQL syntax that they can use on 80% of the RDBMSes in
service, including Postgres, HSQLDB, SQLite, Oracle, and SQL Server. This
is serving them well.

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.

Allowing your students to use a non-standard operator that will fail them the
instant they leave the classroom is serving them badly indeed.

--
Josh Berkus
Aglio Database Solutions
San Francisco

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

But now is too late;-)

My point is more practical: my students know one syntax, I don't have a
lot of hours for the course, most of them won't be software developers but
rather software users, so if I can do more interesting things it is not
bad.

--
Fabien Coelho - coelho@cri.ensmp.fr

* Josh Berkus (josh@agliodbs.com) 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 like PostgreSQL to somehow warn me when I start doing things
like this. It's not my intent to use PostgreSQL-specific SQL in general
so when I start doing it I'd like to know. In some cases there may not
be an option, of course, but especially in cases where there's a 'right
way' I'd love for PostgreSQL to spit out a warning which tells me what
the right way is.

ie: "select * from table_name where column_name != '1';"
Warning: '!=' is not valid SQL, use '<>' instead.

This would help me, at least, write correct and portable SQL. :)

Stephen

Stephen Frost wrote:
-- Start of PGP signed section.

* Josh Berkus (josh@agliodbs.com) 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 like PostgreSQL to somehow warn me when I start doing things
like this. It's not my intent to use PostgreSQL-specific SQL in general
so when I start doing it I'd like to know. In some cases there may not
be an option, of course, but especially in cases where there's a 'right
way' I'd love for PostgreSQL to spit out a warning which tells me what
the right way is.

ie: "select * from table_name where column_name != '1';"
Warning: '!=' is not valid SQL, use '<>' instead.

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

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

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 required for SQL conformance.
Search the archives for "SQL flagger" to learn about some of the
previous discussions. Of course a lot of people will be disappointed
to see that the SQL flagger will complain about nearly every statement
they issue.

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 a C/C++/Java background.
They are used to operators such as == != % && || !... Some of these
are available from pg, some are not, so at the time it is incoherent.

I have such a background, and still don't use != to ask for inequality. The
correct thing to use is <>, because thats what the SQL standards say.

--
17:28:01 up 29 days, 21:55, 2 users, load average: 0.34, 0.31, 0.29
-----------------------------------------------------------------
Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica | DBA, Programador, Administrador
Universidad Nacional
del Litoral
-----------------------------------------------------------------

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, WITH[OUT] OIDS, RULE, ~ regular expressions, arrays, any use of
pg_catalog instead of information_schema (I may be wrong in the list, I
don't have the standard at hand, but I think I'm right in the spirit)...

This is going to be noisy;-)

--
Fabien Coelho - coelho@cri.ensmp.fr

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 SERIAL, TEXT and a bunch of other
types, WITH[OUT] OIDS, RULE, ~ regular expressions, arrays, any use of
pg_catalog instead of information_schema (I may be wrong in the list, I
don't have the standard at hand, but I think I'm right in the spirit)...

This is going to be noisy;-)

Yep, it sure is going to be noisy.

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

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 hurt a lot;-)

So you want to generate warnings for SERIAL, TEXT and a bunch of other
types, WITH[OUT] OIDS, RULE, ~ regular expressions, arrays, any use of
pg_catalog instead of information_schema (I may be wrong in the list, I
don't have the standard at hand, but I think I'm right in the spirit)...

This is going to be noisy;-)

Yep, it sure is going to be noisy.

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;

Just wondering...