Re: [HACKERS] Are we losing momentum?

> >> Where do we want to go with this? It is interesting that it maps
> >> MySQL SHOW commands on top of our existing SHOW syntax in psql.
> >> The patch doesn't look too big.
> >
> > The response to "Are we losing momentum?" isn't to add redundant
> > syntax for nonstandard features that we have no control over.
>
> I'm of two minds about it myself. I don't like trying to play
> follow-the- leader with a moving target. But if you think of it as
> trying to win over converts from MySQL, it seems a lot more
> palatable.

The _only_ reason I added this was to aid in the conversion of MySQL
users who don't know how to navigate their way through psql and
PostgreSQL. If you read through the patch, the extended SHOW commands
are only enabled if you turn them on via the --mysql option or by
setting an option (don't recall at the moment) that way you can turn
these on by default in a person's .psqlrc file. With Win32 coming
down the pipe (right??? *cough cough* :-P), converting existing users
is going to be important for PostgreSQL's long term success if it
seeks to gain market share and momentum.

> It would also be interesting to combine this with Rod's idea of
> driving describe-type queries by table instead of hardwired code.
> Imagine that the backend's "show foo" command first looks for "foo"
> as a GUC variable, as it does now, but upon failing to find one it
> looks in a system table for a query associated with the name "foo".
> If it finds such a query, it runs it and sends back the result.
> Now, not only can we emulate "show tables", but people can easily
> add application-specific "show whatever" commands, which seems
> tremendously cool.

I really like the ability to program in queries or syntaxes into the
backend, but as it stands, SHOW foo would have to be pretty smart to
handle the LIKE clauses and other bits. And how would tab completion
be handled in psql? I can't remember if I implemented stuff like,
SHOW TABLES IN SCHEMA foo, but 'SHOW TABLES LIKE a%' was quite a hit
to the people I have using the patch and I don't see how that'd be
applicable with what has been proposed so far. The extra verbosity
and tab completion-ability is important for the newbie, it's an
interactive environment that lets them learn and explore in a
proactive manner. Having IN SCHEMA vs LIKE handled on the backend
would be a rather complex generic model, but in an ideal world, one
that I'd prefer if done right.

> There are some safety and protection issues to be solved here
> (probably only superusers should be allowed to modify the query
> table, and we should restrict the form of the query to be a single
> SELECT command) but I can't think of any showstoppers. Now that
> we've abandoned backend autocommit there are no technical reasons
> that SHOW shouldn't be allowed to run a SELECT query.
>
> I did not care for the original patch (which IIRC made psql
> recognize "show" commands, rather than doing it in the backend) but
> something like the above seems reasonably clean.

Well, unless something is done very cleanly and abstractly, and can be
extended to handle IN SCHEMA, LIKE, etc., I'm of the opinion that this
kinda stuff belongs on the client side of things and _not_ in the
backend. Putting MySQL's brokenness in the backend seems, well, to
perpetuate the brokenness and acknowledge that their brokenness isn't
really that broken: not a message I'm fond of. Putting MySQL's
brokenness in psql and hiding it behind the --mysql CLI option,
however, is tolerably broken, IMHO and of the same use as ora2pg or
mysql2pg.

Bruce wrote:
> Where do we want to go with this? It is interesting that it maps
> MySQL SHOW commands on top of our existing SHOW syntax in psql. The
> patch doesn't look too big.
>
> Should this be applied? Sean, I know you have a newer patch the the
> URL you posted isn't good anymore. This also contains GUC change.
> Sean, would you show each one you added and we can discuss if any
> are inappropriate.

The GUC change was just flushing out various GUC options that weren't
available as tab completion options... the usefulness of those GUCs
could be debated, but at least there's a complete list in the CLI
now... having this pulled from the server would be wise, IMHO, but I
didn't spend the time to add that at the time. If there's interest, I
can do that.

I have the patch someplace, don't worry about that. The patch isn't
100% correct as it stands: there is a problem in recognizing the end
of a SHOW command so that the query buffer was considered non-empty
(wasn't scanning properly for ;'s to emulate the end of a query:
something that's not necessary with the normal \ syntax). Other than
that, there are no bugs that I'm aware of and the work around is to
issue a \r: not an earth shattering problem given psql has a history.
Before I finished, I wanted to get some review/thoughts on the patch
before I completed the work and sent it off only to have it rejected.

I know Tom doesn't like the idea because it's not "clean," but I can't
help but feel that adding similar functionality to the backend is some
how contaminating PostgreSQL and acknowledges MySQL's done something
creditable, which is too big of an admission, especially since their
product is pretty fundamentally flawed in terms of spec compliance.
The last thing we want is to have their brokenness turn into spec and
for that to become the norm. So, as life would have it, I'm an
advocate of adding the SHOW syntax to psql and an opponent of having it
in the backend, the core developers would rather have the SHOW syntax
in the backend because it's not clean to have it in the front end.
*shrug*

psql has to have a quasi-parser in the front end as is to handle tab
completion, so I don't really buy the argument that it's bad to have a
parser in the front end (sorry Tom). In fact, I actually think that
the parser in psql needs to be _beefed up_ and made _smarter_ that way
psql's more user friendly, even if that means increasing the
complexity of psql. At the moment, there are short falls with psql's
ability to perform tab completion of column names on aliased tables,
etc. Some of it's non-trivial and won't ever see the light of day in
psql, but there is room for improvement. Anyway, usability is a
problem for clients, not for servers. MySQL usability belongs in the
client, not the backend.... and hidden behind a CLI flag at that
'cause I don't available in my personal development environment.

And before someone says, "that's fine and dandy, who's going to do the
work on psql," I'll gladly work on psql and even go so far as to clean
up the code now that someone's around to apply the patches. :)

*listens and waits before updating the patch and fixing the above
bugs* -sc

--
Sean Chittenden