Обсуждение: Case-folding bogosity in new psql
New psql doesn't case-fold in \d command:
regression=# \d DEFAULT_TBL
Did not find any relation named "DEFAULT_TBL".
regression=# \d default_tbl Table "default_tbl"Attribute | Type | Modifier
... etc ...
I'd expect the name of the table to get folded to lower case unless
I put quotes around it. That is in fact how 6.5 psql behaves.
regards, tom lane
This is not a bogosity if you read and understand the psql grammar. Quotes are for protecting whitespace and other metacharacters. For example, in 6.5 there was no good way to connect (\c) to a database with a space in the name. psql tries to emulate one of the popular shells in many places, such as this one. Furthermore single and double quotes also carry the same difference as in shells and Perl. psql is also case sensitive, so \D is not the same as \d, hence DEFAULT_TBL is not the same as default_tbl. The conceptual problem I would have with your idea is that command option interpretation would be inconsistent. For example \e FILE should surely not cause any lower-casing to happen. Now if I'm supposed to pass on the identity of the quote character with every option that's read all the way to the execution phase I'm creating a big hazard. It would furthermore wash away the above mentioned quoting scheme, because double quotes would mean one thing to one kind of command, and another thing to another. I'd agree with your objection if we had a DESCRIBE command or some such, but the psql grammar is different from SQL, and I think it's good to keep that clear. What do other people say about this? On Sun, 30 Jan 2000, Tom Lane wrote: > New psql doesn't case-fold in \d command: > > regression=# \d DEFAULT_TBL > Did not find any relation named "DEFAULT_TBL". > regression=# \d default_tbl > Table "default_tbl" > Attribute | Type | Modifier > ... etc ... > > I'd expect the name of the table to get folded to lower case unless > I put quotes around it. That is in fact how 6.5 psql behaves. > > regards, tom lane > > -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> This is not a bogosity if you read and understand the psql grammar.
In other words, you have (by fiat and with no discussion AFAIR) decided
to change psql's "grammar" so that its handling of names is inconsistent
with the backend's. That might be OK if psql were an independent
product, but it's not. There are already enough discrepancies between
parsing of backslash commands and parsing of SQL commands; do we need
to add more?
> Quotes
> are for protecting whitespace and other metacharacters. For example, in
> 6.5 there was no good way to connect (\c) to a database with a space in
> the name.
That indicates that \c failed to accept quoted names properly --- but
that's just a bug in \c, not a reason to transfer the same breakage
to other places.
> The conceptual problem I would have with your idea is that command option
> interpretation would be inconsistent. For example \e FILE should surely
> not cause any lower-casing to happen.
No, but a filename is not an SQL name. Claiming that filename
interpretation must govern SQL name interpretation is about like
claiming that psql should misinterpret SQL names that happen to
match file names in your current directory.
I think that you have reduced usability considerably in order not to
have to distinguish SQL names and file names in some parts of your
code. That's a design error IMHO.
> What do other people say about this?
I'll wait for other reactions ... but I am not happy.
regards, tom lane
have to agree ... psql behaviour should be an extension of the backend's
...
On Mon, 31 Jan 2000, Tom Lane wrote:
> Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> > This is not a bogosity if you read and understand the psql grammar.
>
> In other words, you have (by fiat and with no discussion AFAIR) decided
> to change psql's "grammar" so that its handling of names is inconsistent
> with the backend's. That might be OK if psql were an independent
> product, but it's not. There are already enough discrepancies between
> parsing of backslash commands and parsing of SQL commands; do we need
> to add more?
>
> > Quotes
> > are for protecting whitespace and other metacharacters. For example, in
> > 6.5 there was no good way to connect (\c) to a database with a space in
> > the name.
>
> That indicates that \c failed to accept quoted names properly --- but
> that's just a bug in \c, not a reason to transfer the same breakage
> to other places.
>
> > The conceptual problem I would have with your idea is that command option
> > interpretation would be inconsistent. For example \e FILE should surely
> > not cause any lower-casing to happen.
>
> No, but a filename is not an SQL name. Claiming that filename
> interpretation must govern SQL name interpretation is about like
> claiming that psql should misinterpret SQL names that happen to
> match file names in your current directory.
>
> I think that you have reduced usability considerably in order not to
> have to distinguish SQL names and file names in some parts of your
> code. That's a design error IMHO.
>
> > What do other people say about this?
>
> I'll wait for other reactions ... but I am not happy.
>
> regards, tom lane
>
> ************
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Mon, 31 Jan 2000, Tom Lane wrote: > Peter Eisentraut <e99re41@DoCS.UU.SE> writes: > > This is not a bogosity if you read and understand the psql grammar. > > In other words, you have (by fiat and with no discussion AFAIR) decided > to change psql's "grammar" so that its handling of names is inconsistent > with the backend's. That might be OK if psql were an independent > product, but it's not. There are already enough discrepancies between > parsing of backslash commands and parsing of SQL commands; do we need > to add more? I have written so many requests for comments on psql, I don't know. This handling of names was nowhere documented, so I couldn't have known it. On the other hand, the current behaviour is documented and consistent with something at least. I totally see what you're saying and I'm going to try to address it. But there was noone who said anything about this so far. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On Mon, 31 Jan 2000, The Hermit Hacker wrote: > > have to agree ... psql behaviour should be an extension of the backend's Okay. Then it shall be ... -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> > have to agree ... psql behaviour should be an extension of the backend's > ... Agreed. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> I have written so many requests for comments on psql, I don't know. This > handling of names was nowhere documented, so I couldn't have known it. On > the other hand, the current behaviour is documented and consistent with > something at least. I totally see what you're saying and I'm going to try > to address it. But there was noone who said anything about this so far. I remember general requests for psql comments, but nothing specific. Of course, my memory may be wrong on this. I do remember some cases in other areas where you did ask for ideas, and we didn't really offer any. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> I totally see what you're saying and I'm going to try
> to address it. But there was noone who said anything
> about this so far.
OK, an overdue comment: the new psql is great (current and future
discrepencies excepted of course ;)
Thanks for sticking with it Peter; we've already got a good
foundation, and as we stumble across these minor differences in
behavior it will get even closer to an ideal interface.
My current favorite feature: command history across psql sessions.
When testing I can jump in and out of psql after rebuilding the
backend and can just uparrow to my last test command. Nice. And for
this case, I won't complain about a lack of backward compatibility :))
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Personal opinion: I think we are coming across a little harder on Peter
then most of us are intending :( I think we're blowing a few
misconceptions a little out of proportion, which is just fueling things
further ...
Peter, I agree with Thomas about the work you are doing, I just tend to
come across 'strong' when I disagree with something ...
On Tue, 1 Feb 2000, Thomas Lockhart wrote:
> > I totally see what you're saying and I'm going to try
> > to address it. But there was noone who said anything
> > about this so far.
>
> OK, an overdue comment: the new psql is great (current and future
> discrepencies excepted of course ;)
>
> Thanks for sticking with it Peter; we've already got a good
> foundation, and as we stumble across these minor differences in
> behavior it will get even closer to an ideal interface.
>
> My current favorite feature: command history across psql sessions.
> When testing I can jump in and out of psql after rebuilding the
> backend and can just uparrow to my last test command. Nice. And for
> this case, I won't complain about a lack of backward compatibility :))
>
> - Thomas
>
> --
> Thomas Lockhart lockhart@alumni.caltech.edu
> South Pasadena, California
>
> ************
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
At 02:37 AM 2/1/00 +0000, Thomas Lockhart wrote: >My current favorite feature: command history across psql sessions. Mine...errors referencing file name and line number. Invaluable when porting over literally thousands of lines of sql from Oracle. Well, technically not "invaluable" since I managed to get an earlier version of this data model ported over 6.5. So I guess we'll have to settle for "damned valuable". Psql's MUCH nicer than SQL*Plus, which doesn't seem to be even dimly aware that it's running on a modern unix system... - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> OK, an overdue comment: the new psql is great (current and future
> discrepencies excepted of course ;)
Agreed. Peter, you've done a really nice job. We're just holding
you to the standards you've proven yourself capable of meeting ;-)
Seriously, it seems like the culture on this list is mostly that
you can expect to hear about it when you break something, but if
you did good you will know it because no one complains...
regards, tom lane
> At 02:37 AM 2/1/00 +0000, Thomas Lockhart wrote: > > >My current favorite feature: command history across psql sessions. > > Mine...errors referencing file name and line number. > > Invaluable when porting over literally thousands of lines of sql > from Oracle. > > Well, technically not "invaluable" since I managed to get an > earlier version of this data model ported over 6.5. > > So I guess we'll have to settle for "damned valuable". > > Psql's MUCH nicer than SQL*Plus, which doesn't seem to be even > dimly aware that it's running on a modern unix system... Yes, many people love psql, and with Peter's additions, it is even better. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Mon, 31 Jan 2000, The Hermit Hacker wrote: > Personal opinion: I think we are coming across a little harder on Peter > then most of us are intending :( I think we're blowing a few > misconceptions a little out of proportion, which is just fueling things > further ... And the subject line doesn't help, IMHO. 'Bogosity' is pretty strong -- 'bugosity' might be better..... However, I understand the possessiveness one gets when one has put forth a great deal of effort into a major project such as this one. > Peter, I agree with Thomas about the work you are doing, I just tend to > come across 'strong' when I disagree with something ... The 'e-mail effect' strikes again. Isn't it so much easier to be much harsher by e-mail than intended? I certainly have noticed that in my decade of being net-connected (first via a slow as molasses uucp link to usenet, then via an even slower slip link....). However, this is quite tame compared to, say, the linux-kernel mailing list..... But, then again, I do believe that the collective net-age of the developers here is higher than on lk, even if the list itself is possibly younger. I say 'kudos' to all the developers who have put in long mostly thankless hours working on this project -- it _is_ worth it!! -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Mon, 31 Jan 2000, Lamar Owen wrote:
> On Mon, 31 Jan 2000, The Hermit Hacker wrote:
> > Personal opinion: I think we are coming across a little harder on Peter
> > then most of us are intending :( I think we're blowing a few
> > misconceptions a little out of proportion, which is just fueling things
> > further ...
>
> And the subject line doesn't help, IMHO. 'Bogosity' is pretty strong --
> 'bugosity' might be better.....
Agreed here too ... I think what has been setting off a lot of the 'red
flags' is a larger then normal number of 'buggy commits' ... stuff that
has to be done, but hasn't been as well thought out/discussed as it should
have been ...
Peter is learning ... in some ways, we threw him into the 'commit arena'
alot faster then we normally would have because of how active/busy he was
... normally, we've waited longer to force the person to get used to how
things operate ... Peter has been getting "on the job training" here :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > > OK, an overdue comment: the new psql is great (current and future > > discrepencies excepted of course ;) > > Agreed. Peter, you've done a really nice job. We're just holding > you to the standards you've proven yourself capable of meeting ;-) > > Seriously, it seems like the culture on this list is mostly that > you can expect to hear about it when you break something, but if > you did good you will know it because no one complains... That should not be the case. How hard is it to e-mail nice things? We need to do better in this area. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Peter is learning ... in some ways, we threw him into the 'commit arena' > alot faster then we normally would have because of how active/busy he was > ... normally, we've waited longer to force the person to get used to how > things operate ... Peter has been getting "on the job training" here :) Agreed. Stick it out, Peter. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
At 10:14 PM 1/31/00 -0500, Tom Lane wrote: >Seriously, it seems like the culture on this list is mostly that >you can expect to hear about it when you break something, but if >you did good you will know it because no one complains... Has it ever been different with any group of talented people? - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.
At 11:24 PM 1/31/00 -0400, The Hermit Hacker wrote: >On Mon, 31 Jan 2000, Lamar Owen wrote: >Agreed here too ... I think what has been setting off a lot of the 'red >flags' is a larger then normal number of 'buggy commits' ... stuff that >has to be done, but hasn't been as well thought out/discussed as it should >have been ... I think a LOT of it had to do with its being committed to the 7.0 sources, which at the time were supposedly going to be released on Feb 1 (tomorrow). If Peter had waited until 7.0 beta then dumped such changes into a new, 7.1 tree with 7.1 some months off I doubt there would've been anything like the reaction he saw. Didn't we all agree recently that this had to do mostly with Peter's misunderstanding of how stable a beta release should be in this project? (as opposed to other projects which run with a "release early, release often" pardigm)? If so, I think we're done with this topic and should be willing to just let it drop. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.