Re: generic copy options

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Emmanuel Cecchet <manu(at)asterdata(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Emmanuel Cecchet <Emmanuel(dot)Cecchet(at)asterdata(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generic copy options
Date: 2009-09-17 04:50:01
Message-ID: 6620.1253163001@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Emmanuel Cecchet <manu(at)asterdata(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-09-17 05:12:09 Re: Feedback on getting rid of VACUUM FULL
Previous Message Pavel Stehule 2009-09-17 04:10:41 Re: generic copy options