MySQL-ism help patch for psql
in [PgSql]
|
Prev: Helping the CommitFest re PL/Perl changes
Next: [HACKERS] MonetDB test says that PostgreSQL often has errors or missing results
From: Bruce Momjian on 19 Jan 2010 15:56 Tom Lane wrote: > Jeff Davis <pgsql(a)j-davis.com> writes: > > That being said, I don't have much of an opinion, so if you see a > > problem, then we can forget it. After all, we would need some kind of a > > prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And > > that defeats a lot of the purpose. > > Yeah, requiring a prefix would make it completely pointless I think. > The submitted patch tries to avoid that by only matching syntax that's > invalid in Postgres, but that certainly limits how far we can go with > it. (And like you, I'm a bit worried about the LOAD case.) > > The last go-round on this was just a couple months ago: > http://archives.postgresql.org/pgsql-bugs/2009-11/msg00241.php > although I guess that was aimed at a slightly different idea, > namely making "show databases" etc actually *work*. This one at > least has a level of complication that's more in keeping with the > possible gain. > > The previous discussion started from the idea that only DESCRIBE, > SHOW DATABASES/TABLES, and USE were worth worrying about. If we > were to agree that we'd go that far and no farther, the potential > conflict with SQL syntax would be pretty limited. I have little > enough experience with mysql to not want to opine too much on how > useful that would be, but it does seem like those are commands > I use right away anytime I am using mysql. Agreed. I think this discussion mirrors the psql 'help' feature we added in 8.4. After a lot of discussion we decided that a limited 'help' functionality was the best approach --- the more we added the less attractive it became. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stefan Kaltenbrunner on 19 Jan 2010 15:58 Tom Lane wrote: > Jeff Davis <pgsql(a)j-davis.com> writes: >> That being said, I don't have much of an opinion, so if you see a >> problem, then we can forget it. After all, we would need some kind of a >> prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And >> that defeats a lot of the purpose. > > Yeah, requiring a prefix would make it completely pointless I think. > The submitted patch tries to avoid that by only matching syntax that's > invalid in Postgres, but that certainly limits how far we can go with > it. (And like you, I'm a bit worried about the LOAD case.) yeah requiring a prefix would make it completely pointless > > The last go-round on this was just a couple months ago: > http://archives.postgresql.org/pgsql-bugs/2009-11/msg00241.php > although I guess that was aimed at a slightly different idea, > namely making "show databases" etc actually *work*. This one at > least has a level of complication that's more in keeping with the > possible gain. well providing a hint that one should use different command will only lead to the path "uhm why not make it work as well" - and we also need to recongnized that our replacements for some of those commands are not really equivalent in most cases. > > The previous discussion started from the idea that only DESCRIBE, > SHOW DATABASES/TABLES, and USE were worth worrying about. If we > were to agree that we'd go that far and no farther, the potential > conflict with SQL syntax would be pretty limited. I have little > enough experience with mysql to not want to opine too much on how > useful that would be, but it does seem like those are commands > I use right away anytime I am using mysql. well those are the most common ones I guess for the current version of the mysql commandline client - but what about future versions or the fact that we only have partial replacements for some of those that people are really asking for? Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 19 Jan 2010 16:12 David Christensen wrote: > > + if (MYSQL_HELP_CHECK("use")) > + { > + MYSQL_HELP_OUTPUT("\\c database"); > + } > [snip] > + else if (MYSQL_HELP_CHECK("load data infile")) > + { > + MYSQL_HELP_OUTPUT("\\copy"); > + } > Quite apart from any considerations covered by other people, these two at least could be positively misleading ... the psql commands are not exact equivalents of the MySQL commands, AIUI. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Christensen on 19 Jan 2010 16:15 On Jan 19, 2010, at 2:58 PM, Stefan Kaltenbrunner wrote: > Tom Lane wrote: >> Jeff Davis <pgsql(a)j-davis.com> writes: >>> That being said, I don't have much of an opinion, so if you see a >>> problem, then we can forget it. After all, we would need some kind >>> of a >>> prefix anyway to avoid conflicting with actual SQL... maybe "\m"? >>> And >>> that defeats a lot of the purpose. >> Yeah, requiring a prefix would make it completely pointless I think. >> The submitted patch tries to avoid that by only matching syntax >> that's >> invalid in Postgres, but that certainly limits how far we can go with >> it. (And like you, I'm a bit worried about the LOAD case.) > > yeah requiring a prefix would make it completely pointless Agreed. >> The last go-round on this was just a couple months ago: >> http://archives.postgresql.org/pgsql-bugs/2009-11/msg00241.php >> although I guess that was aimed at a slightly different idea, >> namely making "show databases" etc actually *work*. This one at >> least has a level of complication that's more in keeping with the >> possible gain. > > well providing a hint that one should use different command will > only lead to the path "uhm why not make it work as well" - and we > also need to recongnized that our replacements for some of those > commands are not really equivalent in most cases. I think if you set this line ahead of time, you don't have to worry about the detractors; this is equivalent to vim outputting "Type :quit<Enter> to exit Vim" when you type emacs' quit sequence. The intent is to show the correct way or to provide a helpful reminder to people new to psql, not to make it work the same. >> The previous discussion started from the idea that only DESCRIBE, >> SHOW DATABASES/TABLES, and USE were worth worrying about. If we >> were to agree that we'd go that far and no farther, the potential >> conflict with SQL syntax would be pretty limited. I have little >> enough experience with mysql to not want to opine too much on how >> useful that would be, but it does seem like those are commands >> I use right away anytime I am using mysql. > > well those are the most common ones I guess for the current version > of the mysql commandline client - but what about future versions or > the fact that we only have partial replacements for some of those > that people are really asking for? I think it captures the intent of the people using the tool, and that it adds a small net benefit in usability for those people. Deciding to support this small subset does not obligate you to expand the scope in the future. (Hey ma, this slope ain't slippery!) Regards, David -- David Christensen End Point Corporation david(a)endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: David Christensen on 19 Jan 2010 16:16
On Jan 19, 2010, at 3:12 PM, Andrew Dunstan wrote: > > > David Christensen wrote: >> >> + if (MYSQL_HELP_CHECK("use")) >> + { >> + MYSQL_HELP_OUTPUT("\\c database"); >> + } >> > [snip] >> + else if (MYSQL_HELP_CHECK("load data >> infile")) >> + { >> + MYSQL_HELP_OUTPUT("\\copy"); >> + } >> > > Quite apart from any considerations covered by other people, these > two at least could be positively misleading ... the psql commands > are not exact equivalents of the MySQL commands, AIUI. The \copy could definitely be considered a stretch; I know \c supports more options than the equivalent USE, but isn't it a proper superset of functionality? Regards, David -- David Christensen End Point Corporation david(a)endpoint.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |