| From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Why forbid "INSERT INTO t () VALUES ();" |
| Date: | 2020-06-25 16:35:20 |
| Message-ID: | CAMsGm5e9RmakEn0zDKKAQ5=oDT42v+jh6Qki6ToX+9hTQ9GSFg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 24 Jun 2020 at 08:18, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> I would like to create an "all defaults" row, i.e. a row composed of the
> default values for all attributes, so I wrote:
>
> INSERT INTO t() VALUES ();
>
> This is forbidden by postgres, and also sqlite.
>
This is not the only area where empty tuples are not supported. Consider:
PRIMARY KEY ()
This should mean the table may only contain a single row, but is not
supported.
Also, GROUP BY supports grouping by no columns, but not in a systematic
way: Using aggregate functions with no explicit GROUP BY clause will result
in grouping by no columns (i.e., entire result set is one group); I also
found that I could GROUP BY NULL::integer, abusing the column number
syntax. But things like GROUP BY ROLLUP () are not supported.
On the plus side, empty rows are supported, although the explicit ROW
keyword is required.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-06-25 16:35:53 | Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path |
| Previous Message | Tom Lane | 2020-06-25 16:33:31 | Re: Open Item: Should non-text EXPLAIN always show properties? |