Re: COPY enhancements
От | Emmanuel Cecchet |
---|---|
Тема | Re: COPY enhancements |
Дата | |
Msg-id | 4AAA9D2F.7070501@asterdata.com обсуждение исходный текст |
Ответ на | Re: COPY enhancements (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: COPY enhancements
|
Список | pgsql-hackers |
Tom Lane wrote: > Robert Haas <robertmhaas@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
В списке pgsql-hackers по дате отправления: