Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
Or look at your CVS/git checkout.
The important point is to look at the grammar, which doesn't have any
idea what the specific options are in the list. (Well, okay, it had
to have special cases for ANALYZE and VERBOSE because those are reserved
words :-(. But future additions will not need to touch the grammar.
In the case of COPY that also means not having to touch psql \copy.)
I understand the convenience from a developer perspective but I wonder
how this improves the user experience. If options are not explicitly
part of the grammar:
- you cannot do automated testing based on the grammar
- it seems that it will be harder to document
- it still requires the same amount of work in psql and 3rd party tools
to support command-completion and so on?
- why only COPY or EXPLAIN would use that syntax? what is the good limit
between an option and something that is part of the grammar?
It looks like passing the current GUC variables as options to COPY.
Isn't there a design problem with the parser if it is so hard to add a
new option to a command? In all cases, both the client and the server
will have to support the new extension (and it will have to be
documented) so it should not make a big difference whether it is
explicitly part of the command grammar or a set of generic options.
manu
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
