> Daevid Vincent wrote:
> > Also, it would be great if mysql client was "smart" enough
> to limit my
> > tab completion choices to possibilities based upon the
> current SQL query
> > I'm crafting. So If I have:
> > "select t[TAB] from ResolveTable join Tickets;"
> > It should only show me columns that start with a 't' that are in the
> > ResolveTable or Tickets tables only.
> How about this as a compromise: if you type ResolveTable.t[TAB],
> only show columns from that table.
I think it already does that. But it sort of defeats the purpose, then I
have to still type out the entire table name each time.
> This would be nice, but then the mysql client would have to
> be able to parse SQL, which is the server's job.
Which brings up a good point. I feel that mySQL should extract the
parser portion out into a library/module so that other things (such as
the client) could use it. Top of my list would be a SQL lint checker. We
have 25+ developers, and if someone checks in a SQL file that is faulty
(maybe forgot a ' mark or a ; or something), then it breaks the build!
We have lint checkers for PHP (php -l foo.php) and a ruby one. But I