Re: generic copy options

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: generic copy options
Дата
Msg-id 18264.1253548785@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: generic copy options  (Emmanuel Cecchet <manu@frogthinker.org>)
Ответы Re: generic copy options  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: TODO item: Allow more complex user/database default GUC settings
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: TODO item: Allow more complex user/database default GUC settings