Re: Add support for logging the current role

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> A user-settable column list seems pretty on-target
>> for solving those problems to me.

> I'm looking into implementing this.

> An interesting initial question is- should the users be able to control
> the *order* of the columns? My gut feeling, if we're giving them a GUC
> that's a list of fields, is 'yes', but I'm happy to listen to other
> thoughts.

Yeah, I was just thinking about that in connection with the suggestion
of using a bitmap as the pre-parsed representation (which would more or
less force adoption of the fixed-column-order approach). I really think
we can't get away with that. Remember what Andrew pointed out upthread:
it's important to be able to load the csvlog output directly into a
table without any extra processing. Suppose a DBA is logging columns
A,B,D and he later realizes that logging C would be a good thing too.
He's going to have to ALTER TABLE ADD COLUMN to add C to his logging
table ... and now it's at the end. This is no problem if he can set the
GUC to be "A,B,D,C" and have the field order be honored. Otherwise he's
got a problem.

In any case, if the GUC representation is a list of field names, I think
the POLA demands that the system honor the list order. You could escape
that expectation by controlling the feature with a pile of booleans
(csv_log_pid = on, csv_log_timestamp = off, etc) but I can't say that
that sort of API appeals to me.

BTW, in case you didn't know, there are some GUCs defined as lists of
identifiers already (look for GUC_LIST bits). Be sure to steal code.

regards, tom lane