On Thu, Jun 25, 2020 at 12:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah, the multi-insert case is a plausible reason that hadn't been
> mentioned before. On the other hand, you can already do that pretty
> painlessly:
Sure, but it means if you're writing code to generate queries
programmatically, then you have to handle the 0-column case completely
differently from all the others. Seems like unnecessary pain for no
real reason.
I mean, I generally agree that if the standard says that syntax X
means Y, we should either make X mean Y, or not support X. But if the
standard says that X has no meaning at all, I don't think it's a
problem for us to make it mean something logical. If we thought
otherwise, we'd have to rip out support for indexes, which would
probably not be a winning move. Now, various people, including you and
I, have made the point that it's bad to give a meaning to some piece
of syntax that is not current part of the standard but might become
part of the standard in the future, because then we might end up with
the standard saying that X means one thing and PostgreSQL thinking
that it means something else. However, that can quickly turn into an
argument against doing anything that we happen not to like, even if
the reason we don't like it has more to do with needing a Snickers bar
than any underlying engineering reality. In a case like this, it's
hard to imagine that () can reasonably mean anything other than a
0-column tuple. It's not impossible that someone could invent another
interpretation, and there's been much discussion on this list about
how the SQL standards committee is more likely than you'd think to
come up with unusual ideas, but I still don't think it's a bad gamble,
especially given the MySQL/MariaDB precedent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
