Re: generic copy options

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: generic copy options
Дата
Msg-id 6620.1253163001@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: generic copy options  (Emmanuel Cecchet <manu@asterdata.com>)
Ответы Re: generic copy options  (Andrew Dunstan <andrew@dunslane.net>)
Re: generic copy options  (Emmanuel Cecchet <manu@asterdata.com>)
Re: generic copy options  (Emmanuel Cecchet <manu@asterdata.com>)
Список pgsql-hackers
Emmanuel Cecchet <manu@asterdata.com> writes:
> Robert Haas wrote:
>>> When we decide to drop the old syntax (in 8.6?), we will be able to clean a
>>> lot especially in psql.

>> Considering that we are still carrying syntax that was deprecated in
>> 7.3, I don't think it's likely that we'll phase out the present syntax
>> anywhere nearly that quickly.

> While I understand the need for the server to still support the syntax, 
> is it necessary for newer version of psql to support the old syntax?

psql has MORE need to support old syntax than the backend does, because
it's supposed to work against old servers.

I wonder though if we couldn't simplify matters.  Offhand it seems to me
that psql doesn't need to validate the command's syntax fully.  All it
really needs to do is find the target filename and replace it with
STDIN/STDOUT.  Could we have it just treat the remainder of the line
literally, and not worry about the details of what the options might be?
Let the backend worry about throwing an error if they're bad.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: generic copy options
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Feedback on getting rid of VACUUM FULL