On Tue, Oct 15, 2013 at 9:47 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-10-15 15:17:58 +0200, Andres Freund wrote: >> If we go for CSV I think we should put the entire primary key as one >> column (containing all the columns) and the entire row another. > > What about columns like: > * action B|I|U|D|C
BEGIN and COMMIT? > * xid > * timestamp > > * tablename > > * key name > * key column names > * key column types > > * new key column values > > * column names > * column types > * column values > > * candidate_key_changed? > * old key column values Repeating the column names for every row strikes me as a nonstarter. If the plugin interface isn't rich enough to provide a convenient way to avoid that, then it needs to be fixed so that it is, because it will be a common requirement. Sure, some people may want JSON or XML output that reiterates the labels every time, but for a lot of people that's going to greatly increase the size of the output and be undesirable for that reason. > What still need to be determined is: > * how do we separate and escape multiple values in one CSV column > * how do we represent NULLs I consider the escaping a key design decision. Ideally, it should be something that's easy to reverse from a scripting language; ideally also, it should be something similar to how we handle COPY. These goals may be in conflict; we'll have to pick something. I'm not sure that having multiple values in one column is a good plan, because now you need multiple levels of parsing to unpack the row. I'd rather just have a flat column list with a key somewhere explaining how to interpret the data. But I'm prepared to give in on that point so long as we can demonstrate that the format can be easily parsed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers