Personally I don't think that this is a "transitional issue" and we willAnd 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.
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 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 theIn 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.
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.
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 laneYes, it's a well known rhetoric technique. Take whatever argument your opponent say, and exagerate it to an absurd.
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.
Shachar
-- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
