Thread: Re: [HACKERS] What can we learn from MySQL?

On Fri, 23 Apr 2004, Shachar Shemesh wrote:

> When I ask about non-standard complience of Pg (turning unquoted
> identifiers to lowercase instead of uppercase, violating the SQL
> standard, and requring an expensive rewrite of clients), and I get the
> answer "uppercase is ugly", I think something is wrong.

I would love if someone fixed pg so that one can get the standard
behaviour. It would however have to be a setting that can be changed so we
are still backward compatible.

> that even if I write a patch to start migration, I'm not likely to get
> it in.

Just changing to uppercase would break old code so such a patch should not
just be commited. But would people stop a patch that is backward
compatible (in the worst case a setting during initdb)? I'm not so sure
they will.

--
/Dennis Björklund

Dennis Bjorklund <db@zigo.dhs.org> writes:
> On Fri, 23 Apr 2004, Shachar Shemesh wrote:
>> When I ask about non-standard complience of Pg (turning unquoted
>> identifiers to lowercase instead of uppercase, violating the SQL
>> standard, and requring an expensive rewrite of clients), and I get the
>> answer "uppercase is ugly", I think something is wrong.

> I would love if someone fixed pg so that one can get the standard
> behaviour. It would however have to be a setting that can be changed so we
> are still backward compatible.

Yes.  There have been repeated discussions about how to do this, but
no one's come up with a solution that seems workable.  See the archives
if you care.

For the foreseeable future, backwards compatibility is going to trump
standards compliance on this point.  That doesn't mean we don't care
about compliance; it does mean that it is not the *only* goal.

I find it a bit odd to be debating this point in this thread, seeing
that one of the big lessons I draw from MySQL is "standards compliance
does not matter"...

            regards, tom lane

On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote:
> On Fri, 23 Apr 2004, Shachar Shemesh wrote:
>
> > When I ask about non-standard complience of Pg (turning unquoted
> > identifiers to lowercase instead of uppercase, violating the SQL
> > standard, and requring an expensive rewrite of clients), and I get the
> > answer "uppercase is ugly", I think something is wrong.
>
> I would love if someone fixed pg so that one can get the standard
> behaviour. It would however have to be a setting that can be changed so we
> are still backward compatible.
>
> > that even if I write a patch to start migration, I'm not likely to get
> > it in.
>
> Just changing to uppercase would break old code so such a patch should not
> just be commited. But would people stop a patch that is backward
> compatible (in the worst case a setting during initdb)? I'm not so sure
> they will.
>

I know this to be true, but don't fully understand it... if our default
behavior is to fold lower, and we change it to just fold upper... then
in theory this shouldn't break anything since what used to be folder
lower will now simply be folder upper. the only people who will have a
problem are those who quote on one end but not the other, which is bad
practice anyways...  so i would say if your serious about it, make the
patch as GUC "case_folding" for upper or lower and get a taste for what
breaks inside the db.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Fri, 23 Apr 2004, Robert Treat wrote:

> On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote:
> > On Fri, 23 Apr 2004, Shachar Shemesh wrote:
> >
> > > When I ask about non-standard complience of Pg (turning unquoted
> > > identifiers to lowercase instead of uppercase, violating the SQL
> > > standard, and requring an expensive rewrite of clients), and I get the
> > > answer "uppercase is ugly", I think something is wrong.
> >
> > I would love if someone fixed pg so that one can get the standard
> > behaviour. It would however have to be a setting that can be changed so we
> > are still backward compatible.
> >
> > > that even if I write a patch to start migration, I'm not likely to get
> > > it in.
> >
> > Just changing to uppercase would break old code so such a patch should not
> > just be commited. But would people stop a patch that is backward
> > compatible (in the worst case a setting during initdb)? I'm not so sure
> > they will.
> >
>
> I know this to be true, but don't fully understand it... if our default
> behavior is to fold lower, and we change it to just fold upper... then
> in theory this shouldn't break anything since what used to be folder
> lower will now simply be folder upper. the only people who will have a
> problem are those who quote on one end but not the other, which is bad
> practice anyways...  so i would say if your serious about it, make the
> patch as GUC "case_folding" for upper or lower and get a taste for what
> breaks inside the db.

I've tried just changing the parser to unconditionally casefold to upper.
First thing that happens is that initdb breaks. In addition, you have
potential issues with comparisons against the catalog's versions of
standard functions as such if you allow the case folding to be changed
after the catalogs are setup.

On Fri, 23 Apr 2004, Shachar Shemesh wrote:

> Stephan Szabo wrote:
>
> >I've tried just changing the parser to unconditionally casefold to upper.
> >First thing that happens is that initdb breaks. In addition, you have
> >potential issues with comparisons against the catalog's versions of
> >standard functions as such if you allow the case folding to be changed
> >after the catalogs are setup.
> >
> >
> That's not the migration path I was thinking of.
>
> What I was thinking of was:
> 1. Have a setting, probably per-session. Per database works too.
> 2. Aside from the folder upper and folder lower, have a third option.
> This is "fold upper, if fails, fold lower. If succeeds, issue a
> warning". This should allow programs that rely on the folding (such as
> initdb) to be debugged during the transition period.

If you can do this in a clean fashion without tromping all around the
code, that'd be reasonable, however, istm that you'd need to either
pre-fold both directions from the given identifier string and pass an
extra copy around or pass the original identifier and its quoted status
and fold on use.  I think either of these are likely to be very intrusive
for what essentially amounts to a transitional feature.

In addition, I'm not sure that this would always work in any case, since
some of those usages may be quoted identifiers that were once generated
from a case-folded string (for example, looking up a name in the catalogs
and quoting it).

On Fri, 23 Apr 2004, Stephan Szabo wrote:

> On Fri, 23 Apr 2004, Shachar Shemesh wrote:
>
> > Stephan Szabo wrote:
> >
> > >I've tried just changing the parser to unconditionally casefold to upper.
> > >First thing that happens is that initdb breaks. In addition, you have
> > >potential issues with comparisons against the catalog's versions of
> > >standard functions as such if you allow the case folding to be changed
> > >after the catalogs are setup.
> > >
> > >
> > That's not the migration path I was thinking of.
> >
> > What I was thinking of was:
> > 1. Have a setting, probably per-session. Per database works too.
> > 2. Aside from the folder upper and folder lower, have a third option.
> > This is "fold upper, if fails, fold lower. If succeeds, issue a
> > warning". This should allow programs that rely on the folding (such as
> > initdb) to be debugged during the transition period.
>
> If you can do this in a clean fashion without tromping all around the
> code, that'd be reasonable, however, istm that you'd need to either
> pre-fold both directions from the given identifier string and pass an
> extra copy around or pass the original identifier and its quoted status
> and fold on use.  I think either of these are likely to be very intrusive
> for what essentially amounts to a transitional feature.
>
> In addition, I'm not sure that this would always work in any case, since
> some of those usages may be quoted identifiers that were once generated
> from a case-folded string (for example, looking up a name in the catalogs
> and quoting it).

To clarify, I'm thinking about things where an application had gotten a
quoted name and is now trying to use it where the object's canonical name
was changed due to quoting changes. This only happens when quoting
is inconsistently applied, but that's most of the problem.

Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> To clarify, I'm thinking about things where an application had gotten a
> quoted name and is now trying to use it where the object's canonical name
> was changed due to quoting changes. This only happens when quoting
> is inconsistently applied, but that's most of the problem.

Actually, that's *all* the problem, at least as far as SQL commands are
concerned.  If you are consistent about always quoting or never quoting
a particular name, you can't tell the difference between PG's behavior
and SQL-spec behavior.

Aside from the reality that apps aren't very consistent about their
quoting behavior, the fly in this ointment is that whenever you query
the database catalogs you will see the stored spelling of the name.
So apps that rely on seeing the same spelling in the catalog that they
entered could break.  (In practice this doesn't seem to be as big a
problem as the sloppy-quoting-behavior issue, though.)

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

            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.

On Sat, 24 Apr 2004, Tom Lane wrote:

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

Well, get used to it :-)

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

Wouldn't the upper case identifiers just be visible in the \d output,
table headers and such. You could still have psql tab completion produce
lower case identifiers (if told using some setting).

Even if the database store all non quoted names as upper case I would
still use lower case in all applications and on the psql command line.

It's not a big problem for me if the output of \d and the table headers
and such is in upper case. One would get used to it fase. And maybe one
can even store an extra bit telling if the string was created with or
without quotes and have psql lower case all the ones created without
quotes.

First I thought that one can store the string with case all the time, and
just convert when needed (when comparing identifiers). Perhaps using the
non existant locale support and locales such as SQL_UPPER or SQL_MIXED.
But it wont work since it would make "Foo" and Foo clash. When translated
directly it would create separate entries "Foo" and "FOO".

ps. And if you want to play the WRITE MAILS USING ONLY UPPER CASE, BE MY
GUEST!

--
/Dennis Björklund

Dennis Bjorklund <db@zigo.dhs.org> writes:
> On Sat, 24 Apr 2004, 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.

> Wouldn't the upper case identifiers just be visible in the \d output,
> table headers and such.

Exactly ... and that's where my readability complaint starts ...

> First I thought that one can store the string with case all the time, and
> just convert when needed (when comparing identifiers).

People keep suggesting these random not-quite-standard behaviors, but
I fail to see the point.  Are you arguing for exact standards
compliance, or not?  If you're not, then you have to make your case on
the claim that "my nonstandard behavior is better than the existing
nonstandard behavior".  Which might be true, beauty being in the eye of
the beholder, but I doubt you can prove it to the extent of overriding
the backwards-compatibility issue.

            regards, tom lane

On Sat, 24 Apr 2004, Tom Lane wrote:

> > First I thought that one can store the string with case all the time, and
> > just convert when needed (when comparing identifiers).
>
> People keep suggesting these random not-quite-standard behaviors, but
> I fail to see the point.  Are you arguing for exact standards
> compliance, or not?

That was me making conversation, pointing out something that does not
work. Since it does not work I don't want it to be implemented. And with
work I mean not follow the standard.

For something to follow standard it has to behave the correct way to the
outside, how it's implemented is a different matter. The above does not
work. Period.

--
/Dennis Björklund

Tom Lane wrote:
> Aside from the reality that apps aren't very consistent about their
> quoting behavior, the fly in this ointment is that whenever you query
> the database catalogs you will see the stored spelling of the name.
> So apps that rely on seeing the same spelling in the catalog that they
> entered could break.  (In practice this doesn't seem to be as big a
> problem as the sloppy-quoting-behavior issue, though.)

Shouldn't apps only really be querying the information schema if they're
expecting spec compliant behavior? If so, a GUC variable with an access
function ought to be enough to get up or down casing as desired, I'd think.

Joe

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.

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

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

On Fri, Apr 23, 2004 at 11:45:28AM -0400, Robert Treat wrote:

> lower will now simply be folder upper. the only people who will have a
> problem are those who quote on one end but not the other, which is bad
> practice anyways...  so i would say if your serious about it, make the
> patch as GUC "case_folding" for upper or lower and get a taste for what
> breaks inside the db.

If it were that easy, it wouldn't matter, right?  That is, if you had
a system which was either consistently quoted or consistently
unquoted, then you'd never run into the problem of the upper-or-lower
question.

It's precisely _because_ systems often have been maintained by
various cranks for 20 years that it's a problem.  One guy thinks
quoting is stupid.  Another thinks that if you don't quote, you're
asking for trouble,  A third has been rigourous in following the
quoting convention he learned in his last job.  The ship date is
three weeks away, and there are 802 "P1" bugs filed.  What chance do
you think there is that someone is going to scrub all the checkins of
quotes (or apply them carefully)?  This is _exactly_ why standards
compliance for this stuff matters, and why backward comaptibility is
also a top priority.

A

--
Andrew Sullivan  | ajs@crankycanuck.ca

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

Stephan Szabo wrote:

>>I know this to be true, but don't fully understand it... if our default
>>behavior is to fold lower, and we change it to just fold upper... then
>>in theory this shouldn't break anything since what used to be folder
>>lower will now simply be folder upper. the only people who will have a
>>problem are those who quote on one end but not the other, which is bad
>>practice anyways...  so i would say if your serious about it, make the
>>patch as GUC "case_folding" for upper or lower and get a taste for what
>>breaks inside the db.
>>
>>
>
>I've tried just changing the parser to unconditionally casefold to upper.
>First thing that happens is that initdb breaks. In addition, you have
>potential issues with comparisons against the catalog's versions of
>standard functions as such if you allow the case folding to be changed
>after the catalogs are setup.
>
>
>

ISTM that rather than a having a GUC setting, initdb would be the right
time to make this choice. I'm not saying it would be easy, but it seems
(without looking into it deeply) at least possible.

cheers

andrew

Stephan Szabo wrote:

>I've tried just changing the parser to unconditionally casefold to upper.
>First thing that happens is that initdb breaks. In addition, you have
>potential issues with comparisons against the catalog's versions of
>standard functions as such if you allow the case folding to be changed
>after the catalogs are setup.
>
>
That's not the migration path I was thinking of.

What I was thinking of was:
1. Have a setting, probably per-session. Per database works too.
2. Aside from the folder upper and folder lower, have a third option.
This is "fold upper, if fails, fold lower. If succeeds, issue a
warning". This should allow programs that rely on the folding (such as
initdb) to be debugged during the transition period.

          Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/

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/

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/

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/

Shachar,

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

Hey, now wait a minute.   As far as I can tell, you've heard only from Tom
Lane on the steering committee (I may have missed some, though, I've been
sick)   Unless the 5 of us take a vote, Tom Lane speaks for Tom Lane, not for
Core.    Also, usually this list or Patches determines by consensus what gets
in; the Core only gets involved in very unusual cases.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:

>Shachar,
>
>
>
>>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.
>>
>>
>
>Hey, now wait a minute.   As far as I can tell, you've heard only from Tom
>Lane on the steering committee (I may have missed some, though, I've been
>sick)
>
Exactly. Of the people I heard from, the wind was against.

>   Unless the 5 of us take a vote, Tom Lane speaks for Tom Lane, not for
>Core.    Also, usually this list or Patches determines by consensus what gets
>in; the Core only gets involved in very unusual cases.
>
>
That's why we are holding an open thread on the "how" in "hackers". I'm
assuming that once the "how" is sufficiently resolved, and the
implications understood, everyone can make a better decision on the "do
we at all".

             Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/