FW: [HACKERS] Do we prefer software that works or software that looks good?
Tom Lane wrote: Personally I don't think that this is a transitional issue and we will someday all be happy in upper-case-only-land. Upper-case-only sucks, by every known measure of readability, and I don't want to have to put up with a database that forces that 1960s-vintage-hardware mindset on me. I think the SQL standard is screwy here on at least two levels. Not only is upper case fuggly (we all seem to agree on that point), but I think case folding is a Bad Idea in general. I think the only time you should have to quote a DB identifier is when it conflicts with a reserved word. Either be case sensative or don't. I'm all for the (ignore but preserve case) way of doing things. But it IS the standard, and as such, as much as we all seem to dislike it, I believe it is better to follow it. You can't just go around picking and choosing the standards you'll adhere to. Like Microsoft. If it bothers you that much, put some effort into changing it. Attain world domination and then force the world to bend to The Right Way. Get rich and pay off enough members of the standards body to get it changed. But until then, live with it. Now, I am all for configurability, and lots of it. By all means, allow us to choose how we'd like case folding to be carried out, or whether case folding (blech) is done at all. While you're at it, allow us to choose whether NULL is treated as zero/blank/empty or as SQL standard NULL. Allow us to force the DB to do case-insensative comparisons on all character data. Allow us, as DB admins, to f*** with the standard behavior until we have a working mimic of MySQL or MS-SQL :-) But I think the default behavior should adhere to the SQL standard as closely as possible, even when we all hate it with a passion. Just my $.02 Glen Parker ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Do we prefer software that works or software that looks good?
On Sat, 24 Apr 2004, Shachar Shemesh wrote: Tom Lane wrote: So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. This seems possible (not easy, but possible) if we are willing to require the choice to be made at compile time ... but that sounds too restrictive to satisfy anybody ... what we need is a design that supports such a choice per-session, and I dunno how to do that. In other words, you are going to reject the simpler solutions that treat this as a transition problem, because of asthetic issue? Not even program design issue, mind you. Sounds strange to me, and also pretty much guarentees that this will never happen. That would be a shame. [ Tom, we know your opinion on the first part of the next paragraph, so you don't need to reply to that part. ;) ] Are we going to get rid of the current behavior entirely? If so, how are we going to handle issues like current databases with names like foo and FOO (and what if the name was given as foo)? If not, when can one set the folding options and how do we (in the long term) make the database work properly in both settings. Things like don't worry about the catalog entries don't fly when your standard functions are defined and looked up there. Depending on the answers to the above, we need to think about things like the transitional plans put forth. Do these plans actually help transition things. The fold up and down compare one then the other on a failure of the first may be fairly invasive changes, still has problems when quotes are used inconsistently and can also silently change behavior from old versions (on that database mentioned above, what does select * from foo do, is it the same as before?). These may or may not be huge issues and it may or may not be easily solvable, but these things need to be figured out IMHO before something can be considered a solution. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Do we prefer software that works or software that looks good?
-Original Message- From: Stephan Szabo [mailto:[EMAIL PROTECTED] Sent: 24 April 2004 08:43 To: Shachar Shemesh Cc: Tom Lane; Robert Treat; Dennis Bjorklund; Bruce Momjian; PostgreSQL-development; PostgreSQL advocacy Subject: Re: [HACKERS] Do we prefer software that works or software that looks good? Are we going to get rid of the current behavior entirely? If so, how are we going to handle issues like current databases with names like foo and FOO (and what if the name was given as foo)? If not, when can one set the folding options and how do we (in the long term) make the database work properly in both settings. Things like don't worry about the catalog entries don't fly when your standard functions are defined and looked up there. I'm unfamiliar with the code involved so this may be a waste of bandwidth, but it seems to me that any selection of upper or lower case folding should be done on a per-database basis - probably specified in the create database statement, and flagged in pg_database. If its done per-database then any issues of FOO == foo go away unless someone loads a lowercase dump into an uppercase database - in which case it's up to them to resolve any conflicts prior to loading the dump file. Regards, Dave. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Do we prefer software that works or software that looks good?
Stephan Szabo wrote: [ Tom, we know your opinion on the first part of the next paragraph, so you don't need to reply to that part. ;) ] Are we going to get rid of the current behavior entirely? I doubt that will be a good idea. You want to let applications created for previous versions of PostgreSQL continue to work. The idea, I think, is to have either a DB wide, or a session wide, option to have it either way. We may have to create a DB conversion tool, that converts a DB from one way to the other (and changes the case of functions, along the way). If so, how are we going to handle issues like current databases with names like foo and FOO (and what if the name was given as foo)? I think these are really rare. The conversion tool can warn about these cases. If not, when can one set the folding options and how do we (in the long term) make the database work properly in both settings. I don't think having the same DB work in both folding options is really a big issue. Having two databases on the same server, one this way and one the other is, however. You don't want to install two database servers, merely because you have two applications developed for two different PG versions. Things like don't worry about the catalog entries don't fly when your standard functions are defined and looked up there. Answer above. Depending on the answers to the above, we need to think about things like the transitional plans put forth. Do these plans actually help transition things. I think they do. The idea is to be as complaining and as verbose during transition as possible. Ideally, if some breakpoint can be triggered each time a double lookup takes place (thus knowing that the client app is calling the wrong way), this will allow converting apps in almost no time at all. The fold up and down compare one then the other on a failure of the first may be fairly invasive changes, In what way invasive? still has problems when quotes are used inconsistently The main issue, as far as I'm concerned, is not with PG apps that need to be ported to the new scheme. I don't have any qualm with never deprecating the lowercase folding. This, of course, puts a burden on utilities that work as infrastructure to always quote or always not-quote (depending on exact semantics), but that, I believe, is solveable. My problem is with applications written for other, more standard complient, databases, and with porting these into PG. As such, if the app uses inconsistent quoting, it today relies on uppercase folding, and will not have any problem. and can also silently change behavior from old versions (on that database mentioned above, what does select * from foo do, is it the same as before?). These may or may not be huge issues and it may or may not be easily solvable, but these things need to be figured out IMHO before something can be considered a solution. I agree. It's just that I don't think this is a big issue, given the fact that I don't think we intend to deprecate the lowercase folding any time soon. Shachar Remove advocacy from the CC. I don't think it's related there any more. -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Do we prefer software that works or software that looks good?
On Saturday 24 April 2004 01:23, Shachar Shemesh wrote:
Tom Lane wrote:
PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE
to make the point about readability. But if you want to argue the
point with me, I'll be happy to do that for the rest of the thread.
Yes, it's a well known rhetoric technique. Take whatever argument your
opponent say, and exagerate it to an absurd.
Kind of like changing the subject line of a thread to imply your side of the
argument is the one that has technical merit and the other side is being
petty and/or frivolous? Anyone who has studied software useability will
know that uppercase should, in general, be avoided as it hurts readability.
It isn't about looking pretty, it's about being more usable.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Do we prefer software that works or software that looks good?
Robert Treat wrote: On Saturday 24 April 2004 01:23, Shachar Shemesh wrote: Tom Lane wrote: PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE to make the point about readability. But if you want to argue the point with me, I'll be happy to do that for the rest of the thread. Yes, it's a well known rhetoric technique. Take whatever argument your opponent say, and exagerate it to an absurd. Kind of like changing the subject line of a thread to imply your side of the argument is the one that has technical merit and the other side is being petty and/or frivolous? It is my understanding that the discussion with Tom was 100% about the question in the subject line. There is no question that the SQL standard dictates that unquoted identifiers should be folded to uppercase. There is no question (not from me) that upper case is ugly. The only question is whether we should prefer standard to asthetic. Anyone who has studied software useability will know that uppercase should, in general, be avoided as it hurts readability. You convinced me! let's change the SQL standard. It isn't about looking pretty, it's about being more usable. Robert Treat Ok. I'm willing to change the subject to are hurting eyes due to uppercase preferable to changing lots of code when migrating to PG from other database due to standard incomplience, if it would make you feel better. The point is that I am not against lower case, or pro uppercase. I HATE uppercase. I do think, however, that standards should be followed. The question is, when all is said and done, which is more useable. A DB that presents unquoted identifiers as uppercase, or one that allows easier migration of client apps from other DBs. I'll also mention that if asthetic/readability is all that bothers you, we can add a flag to psql that displays all caps as lowercase. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Do we prefer software that works or software that looks good?
On Saturday 24 April 2004 08:09, Shachar Shemesh wrote:
Robert Treat wrote:
Anyone who has studied software useability will
know that uppercase should, in general, be avoided as it hurts
readability.
You convinced me! let's change the SQL standard.
We plan to, right after we have PostgreSQL achieve world domination. But we
can't abondon lower case now or it will weaken the argument when that time
comes. :-)
Ok. I'm willing to change the subject to are hurting eyes due to
uppercase preferable to changing lots of code when migrating to PG from
other database due to standard incomplience, if it would make you feel
better.
ouch. s/code when/code from crappily written apps when/:-)
The point is that I am not against lower case, or pro uppercase. I HATE
uppercase. I do think, however, that standards should be followed. The
question is, when all is said and done, which is more useable. A DB that
presents unquoted identifiers as uppercase, or one that allows easier
migration of client apps from other DBs.
IMHO apps that apply quoted identifiers willy nilly are busted anyway, and it
is only by coincidence that they work on other databases if they work at all.
(And it's by extremely unfortunate coincidence that they might be spec
complient in that behavior.. but hey.)
Oh well... let's see if we can find a way to support both...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Do we prefer software that works or software that looks good?
Robert Treat wrote: IMHO apps that apply quoted identifiers willy nilly are busted anyway, Not really. Sometimes the app itself will be very consistent, never applying quotes, but an underlying driver will always apply quotes. The result is a mixed behaviour. There is nothing you or me can do about that. Notice that in the above case, neither app nor driver are violating their mandate, and both are well within their right to do so. So long as the behaviour is regulated by a standard, there is nothing you and I can say against such practices. Oh well... let's see if we can find a way to support both... You are welcome to join the other leg of this thread, then. That one is not CCed to advocacy, as it is 100% technical. Robert Treat Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Do we prefer software that works or software that looks good?
On Sat, 24 Apr 2004, Shachar Shemesh wrote: Stephan Szabo wrote: Are we going to get rid of the current behavior entirely? I doubt that will be a good idea. You want to let applications created for previous versions of PostgreSQL continue to work. The idea, I think, is to have either a DB wide, or a session wide, option to have it either way. We may have to create a DB conversion tool, that converts a DB from one way to the other (and changes the case of functions, along the way). I'm going to assume that we're making the assumption that the user isn't going to try to do this on databases where it doesn't work? I think we've lost any information about quoting (was that named foo or foo?) so I don't think we can meaningfully make a current PostgreSQL app that's inconsistent about quoting work after the conversion. I think this is reasonable, but others may disagree. If so, how are we going to handle issues like current databases with names like foo and FOO (and what if the name was given as foo)? I think these are really rare. The conversion tool can warn about these cases. I agree, but we need to think about these cases (and any other wacky cases like this) so that we can warn about these cases rather than just not handle them. If not, when can one set the folding options and how do we (in the long term) make the database work properly in both settings. I don't think having the same DB work in both folding options is really a big issue. Having two databases on the same server, one this way and one the other is, however. You don't want to install two database servers, merely because you have two applications developed for two different PG versions. To be honest for me, it really doesn't feel much different than an app written for 7.2 and one written for 7.4 where the former uses things that were removed and so cannot be moved to 7.4 without changes. But that's just an option. Things like don't worry about the catalog entries don't fly when your standard functions are defined and looked up there. Answer above. Okay, under that world view (as opposed to on the fly), I think the only issues come in from shared catalogs, most importantly user names. This is certainly solvable, but we need to consider how we handle them when given to commands like ALTER USER or CREATE USER. The fold up and down compare one then the other on a failure of the first may be fairly invasive changes, In what way invasive? Right now AFAIK most of the case folding stuff pretty much happens in one place during normal queries and the identifier string you get out has the post-folding identifier for unquoted or the contained literal for quoted. In a system where you fold both directions, I can see a few obvious options: a) keep around the real identifier that was given plus whether or not it was quoted. b) keep around both folded identifiers (for non-quoted names). c) fold one direction then the other. This may potentially do the wrong thing in some locales I don't know how you were planning to handle this issue so I don't know if any of these scenarios were what you were thinking of or if you had a better idea. I think all of these potentially may need to touch at least some places where the identifier is used and I think all of them need information that is not AFAIK currently returned from scan.l which means passing that information along (which may change stuff along the way). still has problems when quotes are used inconsistently The main issue, as far as I'm concerned, is not with PG apps that need to be ported to the new scheme. I don't have any qualm with never deprecating the lowercase folding. This, of course, puts a burden on utilities that work as infrastructure to always quote or always not-quote (depending on exact semantics), but that, I believe, is solveable. My problem is with applications written for other, more standard complient, databases, and with porting these into PG. As such, if the app uses inconsistent quoting, it today relies on uppercase folding, and will not have any problem. That sounds like a plus for having the option for full uppercase folding. I have no problems with that (I wouldn't have even looked at initdb if I didn't want to give an option for uppercase folding) but I'm not convinced it actually is a plus for the transitional setting. An app written for full uppercase should work in said option without needing the transitional setting and in fact the transitional setting might do the wrong thing for said application. The only place I can see transitional being useful is for upgrading and testing our own stuff (make the server work, make pg_dump work, etc) and for applications moving from supporting only the lowercase to supporting both or only upper. For the former, it doesn't need to be a truly supported feature if it's going in in a single version, and for the latter, I think as many of the wierd change and such
Re: [HACKERS] Do we prefer software that works or software that looks good?
On Saturday 24 April 2004 09:21, Shachar Shemesh wrote:
Robert Treat wrote:
Oh well... let's see if we can find a way to support both...
You are welcome to join the other leg of this thread, then. That one is
not CCed to advocacy, as it is 100% technical.
I'm already there...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[HACKERS] Do we prefer software that works or software that looks good?
Tom Lane wrote: Personally I don't think that this is a transitional issue and we will someday all be happy in upper-case-only-land. Upper-case-only sucks, by every known measure of readability, and I don't want to have to put up with a database that forces that 1960s-vintage-hardware mindset on me. And I was feeling apologetic that I was accusing without a base the good (and I'm not cynical about that last adjective) people of the PostgreSQL of making life more difficult for programmers just because they don't like the asthetics of something which an external standard dictates. I mean, sure, I understand the sentiment. I don't like seeing all-caps either. But allow me to give an allegory from another free software project, one where I am an actual active code contributer. Imagine that Alexandre Juliard, the benevolent dictator for the Wine project, would have had the same attitude. Each time someone would come around saying today function X calls function Y, and this breaks program Z. We need to reverse X and Y, he would reply with But it makes more asthetic/program design/whatever sense to do it the way we do it today. The result would be that Wine would never come to the point where it can run Word, IE and other prominant Windows only applications. The reality of things is that Wine, just like Postgres, work by an external standard. Wine's standard is more strict, less documented, and more broad. However, like it or not, the more you deviate from the standard, the more you require people who want to use your technology to adapt to whatever it is that you do. This doesn't make sense on any level. So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. This seems possible (not easy, but possible) if we are willing to require the choice to be made at compile time ... but that sounds too restrictive to satisfy anybody ... what we need is a design that supports such a choice per-session, and I dunno how to do that. In other words, you are going to reject the simpler solutions that treat this as a transition problem, because of asthetic issue? Not even program design issue, mind you. Sounds strange to me, and also pretty much guarentees that this will never happen. That would be a shame. The reason this would be a shame is because postgres is the same reason this thread was CCed to advocacy to begin with. Databases form a pretty saturated field. If Postgres is to break forward, it needs a niche. The fully-featured databases role is taken (Oracle), and the free database role is taken (MySQL). Postgres CAN take the fuly featured free database niche, but that will need help. The time is ripe, however. The company we're doing my current OLE DB work for has contacted me about this, and they dictated Postgres (MySQL was not nearly enough). They still want to see proof of concept working, but that's my job. However, I'm afraid they might give up if things become too complicated to port. Under such circumstances, every little help Postgres can give may mean the difference between breaking through and staying behind. I really wouldn't like to see such an important help break merely because Tom Lane doesn't like to see uppercase on his database tables list. Now, I'm intending to do the best I can on my end. This does have a pretty heavy cost. It means that the OLE DB driver will parse in details each query, and perform replacements on the query text. This is bug prone, difficult, hurts performance, and just plain wrong from a software design perspective. The current drift of wind, however, means that the PostgreSQL steering commite seems to prefer having a lesser quality driver to seeing ugly uppercase. regards, tom lane PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE to make the point about readability. But if you want to argue the point with me, I'll be happy to do that for the rest of the thread. Yes, it's a well known rhetoric technique. Take whatever argument your opponent say, and exagerate it to an absurd. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
