Обсуждение: BUG #1948: Enhancement Request - INSERT syntax

Поиск
Список
Период
Сортировка

BUG #1948: Enhancement Request - INSERT syntax

От
"test_autoincrement"
Дата:
The following bug has been logged online:

Bug reference:      1948
Logged by:          test_autoincrement
Email address:      tony@marston-home.demon.co.uk
PostgreSQL version: 8.0.3
Operating system:   Windows XP
Description:        Enhancement Request - INSERT syntax
Details:

Currently the INSERT statement requires field names and field values to be
presented in separate lists whereas the UPDATE statement requires each field
and value to be presented in a single string (name='value').

The latter is more usable because if there is any validation failure with a
field it is easy to track down down the value in the query sting that goes
with a particular field name. Compare this with a failure on an INSERT
statement containing a large number of fields - you have to count through
the first list to get the index number of the field name, then you have to
count through the list of values to identify the one which goes with that
field name.

This is not user-friendly, and I think the SQL committee made a big mistake
in defining totally different structures for the INSERT and UPDATE
statements.

MySQL already offers this option, so why can't you?

Re: BUG #1948: Enhancement Request - INSERT syntax

От
"Jim C. Nasby"
Дата:
On Sat, Oct 08, 2005 at 12:49:58PM +0100, test_autoincrement wrote:
> This is not user-friendly, and I think the SQL committee made a big mistake
> in defining totally different structures for the INSERT and UPDATE
> statements.
Matter of opinion.

> MySQL already offers this option, so why can't you?

MySQL also thinks it's OK to truncate data. Comparing PostgreSQL to them
isn't a very good way to go about getting a feature added.

Ultimately, I highly doubt that anyone on -hackers has any interest in
this, so it's very unlikely to get done unless you do it yourself (or
pay someone to do it). Even then I suspect -hackers might reject it.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461