Re: psql: Allow editing query results with \gedit - Mailing list pgsql-hackers

Re: Robert Haas
> Based on these comments and the one from David Johnston, I think there
> is a consensus that we do not want this patch, so I'm marking it as
> Rejected in the CommitFest application. If I've misunderstood the
> situation, then please feel free to change the status accordingly.

Hi Robert,

thanks for looking at the patch.

> I feel slightly bad about rejecting this not only because rejecting
> patches that people have put work into sucks but also because (1) I do
> understand why it could be useful to have something like this and (2)
> I think in many ways the patch is quite well-considered, e.g. it has
> options like table and key to work around cases where the naive logic
> doesn't get the right answer. But I also do understand why the
> reactions thus far have been skeptical: there's a lot of pretty
> magical stuff in this patch. That's a reliability concern: when you
> type \gedit and it works, that's cool, but sometimes it isn't going to
> work, and you're not always going to understand why, and you can
> probably fix a lot of those cases by using the "table" or "key"
> options, but you have to know they exist, and you have to realize that
> they're needed, and the whole thing is suddenly a lot less convenient.
> I think if we add this feature, a bunch of people won't notice, but
> among those who do, I bet there will be a pretty good chance of people
> complaining about cases that don't work, and perhaps not understanding
> why they don't work, and I suspect fixing some of those complaints may
> require something pretty close to solving the halting problem. :-(

That's a good summary of the situation, thanks.

I still think the feature would be cool to have, but admittedly, in
the meantime I've had cases myself where the automatism went into the
wrong direction (updating key columns results in DELETE-INSERT cycles
that aren't doing the right thing if you didn't select all columns
originally), so I now understand the objections and agree people were
right about that. This could be fixed by feeding the resulting
commands through another editor round, but that just adds complexity
instead of removing confusion.

I think there is a pretty straightforward way to address the problems,
though: instead of letting the user edit JSON, format the query result
in the form of UPDATE commands and let the user edit them. As Tom said
upthread:

Tom> The stated complaint was "it's too hard to build UPDATE commands",
Tom> which I can sympathize with.

... which this would perfectly address - it's building the commands.

The editor will have a bit more clutter (the UPDATE SET WHERE
boilerplate), and the fields are somewhat out of order (the key at the
end), but SQL commands are what people understand, and there is
absolutely no ambiguity on what is going to be executed since the
commands are exactly what is leaving the editor.

> Now maybe that's all wrong and we should adopt this patch with
> enthusiasm, but if so, we need the patch to have significantly more +1
> votes than -1 votes, and right now the reverse seems to be the case.

I'll update the patch and ask here. Thanks!

Christoph