On Mon, Oct 28, 2019 at 7:21 PM Andres Freund <and...@anarazel.de> wrote: > Because that's the normal way to represent something non-existing for > formats like json? There's a lot of information we show always for !text > format, even if not really applicable to the context (e.g. Triggers for > select statements). I think there's an argument to made to deviate in > this case, but I don't think it's obvious.
I've consistently been of the view that anyone who thinks that the FORMAT option should affect what information gets displayed doesn't understand the meaning of the word "format." And I still feel that way. I also think that conditionally renaming "Output" to "Project" is a super-bad idea. The idea of a format like this is that the "keys" stay constant and the values change. If you need to tell people more, you add more keys. I also think that making the Filter field a group conditionally is a bad idea, for similar reasons. But making it always be a group doesn't necessarily seem like a bad idea. I think, though, that you could handle this in other ways, like by suffixing existing keys. e.g. if you've got Index-Qual and Filter, just do Index-Qual-JIT and Filter-JIT and call it good. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
