Thread: make == as = ?
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 must be dealt with in the backend. I would prefer a backend solution, so that == is also always =. -- Fabien Coelho - coelho@cri.ensmp.fr
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.
> 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
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
* 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, Pennsylvania19073
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, Pennsylvania19073
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...
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 > > > > > > 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; I think a boolean that turns on warnings would be enough. -- 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, Pennsylvania19073
> > 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: sql_version = sql2/sql92/sql3/sql99/postgresql/oracle/mysql/extended Or maybe with a simple integer... sql_strict_compliance = on/off On strict, errors could be generated for incompatible features in user sql queries. Otherwise, only warnings or notice appear for misfeatures. It would be possible to mimic (theoretically) other SQL implementations. With "extended", I could have c-like operators;-) : ! && || == != Still dreaming. -- Fabien Coelho - coelho@cri.ensmp.fr
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) 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. Well, I can have different opinions, depending on the standpoint;-) (1) as a sql developer, I may want to have a tool that helps me write portable and standard code. Well, if I know thereis a standard. Otherwise, I just want to code, and the more feature the better. (2) as a product developer, I may want to serve all my customers, whether they are of the "standard" type or not. (3) as a product marketer, I may want that my product as distinguishable features so that I can "sell" it because it doesmore that the standard. I've been involved in a Fortran research compiler, and I assure you that you must support extensions (sun cray...) if you want to take real industrial codes. 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 not sure it will be accepted;-) Moreover, having == as a synonym for = is not necessarily in contradiction with a stable, reliable and predictable server. > AND is not an operator, ... The docs says "logical operator". Maybe you mean "is not a pg_operator". -- Fabien Coelho - coelho@cri.ensmp.fr
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 not sure > it will be accepted;-) > > Moreover, having == as a synonym for = is not necessarily in > contradiction with a stable, reliable and predictable server. Nobody is suggesting that we should not support legacy features that are non-standard, nor even that we should not occasionally, and for very good reasons, introduce new non-standard features (e.g. dollar quoting). But making == a synonym for = is just syntactic sugar, of no obvious practical benefit that I can see. I think its alleged utility in teaching C/Java/perl programmers is overstated - if they think of == as equality will they also think of = as assignment? And the fact that C (stupidly) uses = for assignment is the whole reason for the existence of == in the first place, and many languages (e.g. see the algol family) do not suffer from this defect. The last reason I advance against this is that operator space is scarce, and if we do use == somewhere it should be to some better purpose than this. cheers andrew
> 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 teaching C/Java/perl programmers is > overstated - if they think of == as equality will they also think of = > as assignment? Maybe. The good news is that = is already used for assignment in SQL (UPDATE foo SET bla=zzz), so it is already C-compatible;-) ;-) > And the fact that C (stupidly) uses = for assignment is the whole reason > for the existence of == in the first place, and many languages (e.g. see > the algol family) do not suffer from this defect. I'm not claiming that C choices were good. > The last reason I advance against this is that operator space is scarce, ??? [!=<>+-*/%&~@]+ does not look scarce to me. Postgres has the largest operator space I ever seen! > and if we do use == somewhere it should be to some better purpose than > this. I'm not sure it would be good to have "==" meaning anything but "=", as a lot of people are "used" to C/C++/java/perl. Anyway, << bonnes Paques >>, -- Fabien Coelho - coelho@cri.ensmp.fr
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 operators. But they're not going to be included in the core distribution. We value the SQL standard on this project, and we're not going to include a bunch of non-standard operators just becuase it's convenient for some people to remember. Please see my previous e-mail about the value of international standards for educators. -- Josh Berkus Aglio Database Solutions San Francisco
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. It does not work correctly. Maybe because of my lack of know how: 1/ the operator precedence is not right. a || b && c is interpreted as (a || b) && c because new operators are simply left associative. I have found where I canset the operator precedence in pg_operator. 2/ you cannot add simply '==' for not-yet-defined types. 3/ the optimizer should need to know about AND/OR/NOT semantics. Also, a partial index with a AND won't be used with "&&". > In fact, you could launch a project on pgFoundry (as soon as it's up) > for a package of C-like operators. Sure. The package just need to fix the backend parser. Adding these features is a 10 lines patch. I'm going to found a new project for a 10 lines patch... Also, I thought - wrongly - that it might be useful to others, and would not hurt anyone. Definitly not a shared point of view from the answers I get! Moreover, I noticed so many "convenient non standard" features in postgresql that suggesting one more did not seem so stupid to me at first glance. > But they're not going to be included in the core distribution. We value > the SQL standard on this project, and we're not going to include a bunch > of non-standard operators just becuase it's convenient for some people > to remember. Good. I'll try to remember that. > 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" and "formation". - "education" means teaching how to think right. so I teach "programming". It may be with java or pascal or c#... the syntaxis not important. what is important is types, functions, control structures... - "formation" means learning a specific skill. for this purpose, I could have "java-programming", and java details arereally important in this course. "int and long differ, although in C int and long may or may not differ". That will serve them differently. Have a nice day, -- Fabien Coelho - coelho@cri.ensmp.fr
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" and "formation". > > - "education" means teaching how to think right. > so I teach "programming". > It may be with java or pascal or c#... the syntax is not important. > what is important is types, functions, control structures... > > - "formation" means learning a specific skill. > for this purpose, I could have "java-programming", and java details > are really important in this course. "int and long differ, although in > C int and long may or may not differ". However given that java's == and SQL = and java's && and SQL AND have different semantics in some cases are you sure you want to teach them something that's actually incorrect in any case. Saying "same as java" is not any help to your students when they run into cases where string or date comparison with == is not the same as in java or foo.a=bar.a && <some condition containing 1/foo.a> errors with a division by 0 when there are no 0 values in bar.a.
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 you to understand it because you seem interested in being an active participant in the community. > Also, I thought - wrongly - that it might be useful to others, and > would not hurt anyone. > > Definitly not a shared point of view from the answers I get! Correct. What a lot of people disagree on is the "would not hurt anybody". > Moreover, I noticed so many "convenient non standard" features in > postgresql that suggesting one more did not seem so stupid to me at first > glance. Well, what several people have been trying to explain is that this is different. We have non-standard syntax for 3 reasons: 1) It's a legacy from when we didn't know any better (example: !=) 2) The syntax supports features that are simply not available under the SQL spec (example, LIMIT or SELECT DISTINCT ON). 3) The syntax supports the Object-Relational extensions of PostgreSQL, and were developed before the publication of O-R syntax in the SQL99 spec, so our syntax differs. The addition of an == operator as a synonym for = does not fall into any of those three groups. Adding == would cause harm in the following three ways: 1) It would impair portability between PostgreSQL and other databases that support the SQL standard. 2) It would be one more operator to maintain between distributions 3) It would, in my opinion, confuse Java and C coders instead of helping them. The last point is very important for your purposes. Let me explain by allegory: I speak a little Spanish and a little Italian, but neither fluently. When I was learning Italian, one of the biggest things to get in my way was my knowledge of Spanish ... the grammar is almost the same, some words are the same, and some of the phonetics are the same ... but not all. I can't tell you how many times I embarassed myself in Italian class by swapping in a Spaish word in an Italian sentence, or worse, speaking Italian with a Mexican accent! But I had no problem whatsoever keeping my Italian and my Nepali seperate, because the two languages are not at all similar. Adding an == operator to the SQL syntax would be the same. 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. SQL and Java are radically different languages based on entirely different priniciples (which is why SQLJ is a stupid idea as well, IMHO). Finally, when your students leave your classroom and need to write a program that interfaces with Oracle or SQL Server, then what? They'll look at their notebooks from class and try the examples, and get a "syntax error." > - "formation" means learning a specific skill. > for this purpose, I could have "java-programming", and java details > are really important in this course. "int and long differ, although in > C int and long may or may not differ". > > That will serve them differently. Remind me to avoid "formation" courses in France, then. From my perspective, it is better to teach a student nothing at all than to teach them something which is wrong. -- Josh Berkus Aglio Database Solutions San Francisco
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. Oracle, M$ and others spend a lot of energy so that what you write for their tool won't be so easilly portable, thus once you've started with them, you'll stay forever. You're arguing that pg should help its "customers" to leave it easilly, what is quite paradoxical! ;-) > 3) It would, in my opinion, confuse Java and C coders I have different classes, and not all classes would be elligible to a '==' for '=' shorthand (well, I should write long-hand as it is longer;-). So I partially aggree with your opinion. > 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 no corner cases, just concepts and basic practice. They are not going to be db developers, not even computer professionnals for most of them. I want them to remember that there is something beside word, powerpoint and excel;-) > Finally, when your students leave your classroom and need to write a program > that interfaces with Oracle or SQL Server, then what? They'll look at their > notebooks from class and try the examples, and get a "syntax error." Sure. They should have used postgresql ;-) > From my perspective, it is better to teach a student nothing at all than > to teach them something which is wrong. "Formation" is what you need to get a job. "Education" is what you need as a human being. We need both... Have a nice day, -- Fabien Coelho - coelho@cri.ensmp.fr
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 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... ;)
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 text/date/... are "basic" types in SQL. Maybe I'm lucky... they could prefer java references with new/equals...;-) If I take your example about details of && vs AND semantics, while teaching "programming concepts" I'm not going to discuss the fact that && is shortcut by the evaluator, as this is very specific. I'm not planing my students to know what "i=++i+i++;" could mean. If I teach about "java/c/c++/java", this may be an issue. So it depends on the course goal. Well, I'm happy that so many people have ideas about what to teach and how to teach it;-) Have a nice day, -- Fabien Coelho - coelho@cri.ensmp.fr
Fabien, > You're arguing that pg should help its "customers" to leave it easilly, > what is quite paradoxical! ;-) <grin> If we're going to "embrace and extend", we need more market share first. ;-) -- Josh Berkus Aglio Database Solutions San Francisco
> > 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 text/date/... are "basic" types in SQL. > Maybe I'm lucky... they could prefer java references with new/equals...;-) > > If I take your example about details of && vs AND semantics, while > teaching "programming concepts" I'm not going to discuss the fact that && > is shortcut by the evaluator, as this is very specific. > > I'm not planing my students to know what "i=++i+i++;" could mean. And I wouldn't expect that in a programming concepts course. But, if you're going to (for example) say that, "preincrement and postincrement work exactly as in C," you've got to realize that there's a chance a student will know that the i++ + ++i is undefined and expect it to be undefined in the language you're talking about. That's the problem with using shorthand phrases like "exactly in <X>" without the "except ..."
Fabien COELHO <coelho@cri.ensmp.fr> 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 between PostgreSQL and other databases that > > support the SQL standard. > > Oracle, M$ and others spend a lot of energy so that what you write for > their tool won't be so easilly portable, thus once you've started with > them, you'll stay forever. > > You're arguing that pg should help its "customers" to leave it easilly, > what is quite paradoxical! ;-) [remainder elided] Perhaps the PostgreSQL community is sufficiently confident in the quality of its product that it doesn't feel the need to resort to odious lock-in tricks? ;) Jim