I think that it is a good idea, but do you can show to us what do you have in mind with a example?
Regards "The hurry is enemy of the success: for that reason.......Be patient" Ing. Marcos L. Ortiz Valmaseda Línea Soporte y Despliegue Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD) Linux User # 418229 PostgreSQL User http://www.postgresql.org http://www.planetpostgresql.org/ http://www.postgresql-es.org/ ----- Mensaje original ----- De: "Emmanuel Cecchet" <m...@frogthinker.org> Para: "Robert Haas" <robertmh...@gmail.com> CC: "Emmanuel Cecchet" <m...@asterdata.com>, "Tom Lane" <t...@sss.pgh.pa.us>, "Emmanuel Cecchet" <emmanuel.cecc...@asterdata.com>, "Josh Berkus" <j...@agliodbs.com>, "PostgreSQL-development" <pgsql-hackers@postgresql.org> Enviados: Domingo, 20 de Septiembre 2009 16:24:28 GMT -10:00 Hawai Asunto: Re: [HACKERS] generic copy options 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. I can provide an implementation of that if this looks interesting to anyone. Emmanuel Robert Haas wrote: > On Sun, Sep 20, 2009 at 2:25 PM, Emmanuel Cecchet <m...@asterdata.com> wrote: > >> Tom Lane wrote: >> >>> Emmanuel Cecchet <m...@asterdata.com> writes: >>> >>>> Here you will force every format to use the same set of options >>>> >>> How does this "force" any such thing? >>> >>> >> As far as I understand it, every format will have to handle every format >> options that may exist so that they can either implement it or throw an >> error. >> > > I don't think this is really true. To be honest with you, I think > it's exactly backwards. The way the option-parsing logic works, we > parse each option individually FIRST. Then at the end we do > cross-checks to see whether there is an incompatibility in the > combination specified. So if two different formats support the same > option, we just change the cross-check to say that foo is OK with > either format bar or format baz. On the other hand, if we split the > option into bar_foo and baz_foo, then the first loop that does the > initial parsing has to support both cases, and then you still need a > separate cross-check for each one. > > >> That would argue in favor of a format option that defines the format. Right >> now I find it bogus to have to say (csv on, csv_header on). If csv_header is >> on that should imply csv on. >> The only problem I have is that it is not obvious what options are generic >> COPY options and what are options of an option (like format options). >> So maybe a tradeoff is to differentiate format specific options like in: >> (delimiter '.', format csv, format_header, format_escape...) >> This should also make clear if someone develops a new format what options >> need to be addressed. >> > > I think this is a false dichotomy. It isn't necessarily the case that > every format will support a delimiter option either. For example, if > we were to add an XML or JSON format (which I'm not at all convinced > is a good idea, but I'm sure someone is going to propose it!) it > certainly won't support specifying an arbitrary delimiter. > > IOW, *every* format will have different needs and we can't necessarily > know which options will be applicable to those needs. But as long as > we agree that we won't use the same option for two different > format-specific options with wildly different semantics, I don't think > that undecorated names are going to cause us much trouble. It's also > less typing. > > >> PS: I don't know why but as I write this message I already feel that Tom >> hates this new proposal :-D >> > > I get those feeling sometimes myself. :-) Anyway, FWIW, I think Tom > has analyzed this one correctly... > > ...Robert > > -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: m...@frogthinker.org Skype: emmanuel_cecchet -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
