Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2020-06-25 18:07, Tom Lane wrote:
> >So I'm still not convinced we should do this. "MySQL is incapable
> >of conforming to the standard" is a really lousy reason for us to do
> >something.
>
> Conformance to the standar
Hello Isaac,
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.
Yep. This is exactly the kind of case about which I was trying the
command, after reading Bruce Momjian blo
On 2020-06-25 18:07, Tom Lane wrote:
So I'm still not convinced we should do this. "MySQL is incapable
of conforming to the standard" is a really lousy reason for us to do
something.
Conformance to the standard means that the syntax described in the
standard behaves as specified in the standa
On Thu, Jun 25, 2020 at 12:07 PM Tom Lane 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
On Wed, 24 Jun 2020 at 08:18, Fabien COELHO 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 e
Robert Haas writes:
> On Thu, Jun 25, 2020 at 12:56 AM Fabien COELHO wrote:
>> It also means that if for some reason someone wants to insert several such
>> all-default rows, they have to repeat the insert, as "VALUES (), ();"
>> would not work, so it is also losing a corner-corner case capabilit
On Thu, Jun 25, 2020 at 12:56 AM Fabien COELHO wrote:
> It also means that if for some reason someone wants to insert several such
> all-default rows, they have to repeat the insert, as "VALUES (), ();"
> would not work, so it is also losing a corner-corner case capability
> without obvious reason
Bonjour Vik,
It's forbidden because the SQL standard forbids it.
Ok, that is definitely a reason. I'm not sure it is a good reason, though.
It's a very good reason. It might not be good *enough*, but it is a
good reason.
Ok for good, although paradoxically not "good enough":-)
Why wou
On Thu, 25 Jun 2020 at 16:56, Fabien COELHO wrote:
> It also means that if for some reason someone wants to insert several such
> all-default rows, they have to repeat the insert, as "VALUES (), ();"
> would not work, so it is also losing a corner-corner case capability
> without obvious reason.
On 6/25/20 6:56 AM, Fabien COELHO wrote:
>
> Hello Tom,
>
> INSERT INTO t() VALUES ();
>>
>>> I'm still unclear why it would be forbidden though, it seems logical to
>>> try that, whereas the working one is quite away from the usual syntax.
>>
>> It's forbidden because the SQL standard forb
Hello Tom,
INSERT INTO t() VALUES ();
I'm still unclear why it would be forbidden though, it seems logical to
try that, whereas the working one is quite away from the usual syntax.
It's forbidden because the SQL standard forbids it.
Ok, that is definitely a reason. I'm not sure it is
On Wed, Jun 24, 2020 at 3:31 PM Dagfinn Ilmari Mannsåker
wrote:
> FWIW, MySQL (and MariaDB) only support INSERT INTO t () VALUES (), not
> DEFAULT VALUES.
We have added syntax for MySQL compatibility in the
> past, e.g. the CONCAT() function.
>
I don't see the similarities. IIUC there isn't a
Tom Lane writes:
> Fabien COELHO writes:
INSERT INTO t() VALUES ();
>
>> I'm still unclear why it would be forbidden though, it seems logical to
>> try that, whereas the working one is quite away from the usual syntax.
>
> It's forbidden because the SQL standard forbids it.
>
> We allow
Fabien COELHO writes:
>>> INSERT INTO t() VALUES ();
> I'm still unclear why it would be forbidden though, it seems logical to
> try that, whereas the working one is quite away from the usual syntax.
It's forbidden because the SQL standard forbids it.
We allow zero-column syntaxes in some ot
Hallo Thomas,
INSERT INTO t() VALUES ();
This is forbidden by postgres, and also sqlite.
Is there any good reason why this should be the case?
Maybe because
insert into t default values;
exists (and is standard SQL if I'm not mistaken)
That's a nice alternative I did not notice. Wel
Fabien COELHO schrieb am 24.06.2020 um 14:18:
> 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.
>
> Is there any good reason why this shoul
Hello devs,
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.
Is there any good reason why this should be the case?
--
Fabien.
17 matches
Mail list logo
