Re: generic copy options - Mailing list pgsql-hackers

From Tom Lane
Subject Re: generic copy options
Date
Msg-id 18264.1253548785@sss.pgh.pa.us
Whole thread Raw
In response to Re: generic copy options  (Emmanuel Cecchet <manu@frogthinker.org>)
Responses Re: generic copy options
List pgsql-hackers
Emmanuel Cecchet <manu@frogthinker.org> writes:
> The easiest for both implementation and documentation might just be to 
> have a matrix of options.
> Each option has a row and a column in the matrix. The intersection of a 
> row and a column is set to 0 if options are not compatible and set to 1 
> if it is. This way we are sure to capture all possible combinations.
> This way, each time we find a new option, we just have to check in the 
> matrix if it is compatible with the already existing options. Note that 
> we can also replace the 0 with an index in an error message array.

This seems like overkill at the moment.  Maybe when/if we get to
actually supporting three or more COPY formats, we'd need it.  Right
now all we are trying to do is make the grammar not be a factor in
adding options, and the foreseen new options aren't about new formats
at all.  So I'm inclined to just fix the grammar and not do
any refactoring of the code in copy.c.

As far as I can tell, the majority opinion is to use "format csv" and
not have the "csv_" prefixes on the options, so I will adjust the patch
accordingly and commit it (barring any other problems coming up when
I read it more closely).
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: TODO item: Allow more complex user/database default GUC settings
Next
From: Alvaro Herrera
Date:
Subject: Re: TODO item: Allow more complex user/database default GUC settings