feature suggestion

Rafael Azevedo wrote:

People,

I'd like to suggest you guys to implement a new feature.
Actually is an alias for a existent feature.

Unstead of having to type all the insert syntax, using ("column") names, you
could do the same as MySQL does.
for example:

INSERT INTO Table SET
"Field1" = 'text',
"Field2" = 'text';

So it would make it easier and faster to develop applications using Postgre.

There is an SQL standard way to do this and we have no intention of
extending that. If you want standard code, use the standard syntax.
MySQL, if it supports this, is just encouraging you to write
non-standard SQL. You can complain to them.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

"Rafael Azevedo" <rafael@webpro.com.br> writes:

Unstead of having to type all the insert syntax, using ("column") names, you
could do the same as MySQL does.
for example:

INSERT INTO Table SET
"Field1" = 'text',
"Field2" = 'text';

So it would make it easier and faster to develop applications using Postgre.

I'm a bit mystified here. What exactly about this syntax is easier or faster?
You still have to list all the column names. It looks like it would require
just as much typing as the regular syntax, no?

Or is it that you get to reuse the same string you use for doing an update?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark wrote:

"Rafael Azevedo" <rafael@webpro.com.br> writes:

Unstead of having to type all the insert syntax, using ("column") names, you
could do the same as MySQL does.
for example:

INSERT INTO Table SET
"Field1" = 'text',
"Field2" = 'text';

So it would make it easier and faster to develop applications using Postgre.

I'm a bit mystified here. What exactly about this syntax is easier or faster?
You still have to list all the column names. It looks like it would require
just as much typing as the regular syntax, no?

Or is it that you get to reuse the same string you use for doing an update?

As far as I can see, the _feature_ is matching MySQL optional
non-standard syntax.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Imagine that you have about 30 fields.
Ok, then your first SQL is done.
Now, you just have to add 10 more fields.
Its very easy to get lost. If we have this implementation, you could just
add

Field31 = 'text',
Field32 = 'text'
...
wherever you want.

This is just a PLUS. I just don't see any problem by doing this.
Even knowing that this is not Standard SQL-Syntax, I just see this as a
benefit feature.

Another reason is that we have more people migrating from MySQL to Postgre
than any other database server. People don't migrate to Postgre from Oracle.
Hardly from MS SQL Server.

It just makes easier to migrate users from other db servers.
And this is sure not hard to implement.

Today its easier to migrate to PostgreSQL from MySQL than from PostgreSQL to
MySQL.

In few words I have given you more reason to add this feature than not to
add it.

Think about it.

2007/7/31, Rafael Azevedo <rafael@webpro.com.br>:

Rafael,

This is just a PLUS. I just don't see any problem by doing this.
Even knowing that this is not Standard SQL-Syntax, I just see this as a
benefit feature.

Our project has a policy of upholding the SQL standard whereever possible.
For that reason, we don't approve non-standard syntax just for reasons of
accessibility. Any non-standard syntax we approve needs to add
significant extra functionality to the DBMS, not just convenience, and
certainly not because MySQL does it.

"Standards are important" is one of the themes of PostgreSQL which
differentiates us from MySQL.

Another reason is that we have more people migrating from MySQL to
Postgre than any other database server. People don't migrate to Postgre
from Oracle. Hardly from MS SQL Server.

You're mistaken. I think we get more migrations from Oracle than from
MySQL. And quite a few from DB2 and Informix.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

On 8/1/07, Rafael Azevedo <rafael@webpro.com.br> wrote:

Imagine that you have about 30 fields.
Ok, then your first SQL is done.
Now, you just have to add 10 more fields.
Its very easy to get lost. If we have this implementation, you could just
add

Field31 = 'text',
Field32 = 'text'

I have to admit this syntax has a lot of advantages over the
insert...values statement, especially in dynamic sql situations. That
being said, more and more I just write queries insert..select which
would be an awkward fit. mysql compatibility is usually pretty poor
justification of a feature (they have a million ways to do everything)
and things have to stand on general merit.

It is really quite unfortunate the way certain aspects of the sql
standard evolved (indirectly causing these types of issues) but that
is a topic for another day :)

merlin

Well. Ok.
Then I'll just do it myself.
Just thought it would be good for thousands of users.
As I said, it was just a suggestion.
I surely aint the only one who ever thought about it.

Thanks anyway.

2007/7/31, Josh Berkus <josh@agliodbs.com>:

Rafael,

This is just a PLUS. I just don't see any problem by doing this.
Even knowing that this is not Standard SQL-Syntax, I just see this as a
benefit feature.

Our project has a policy of upholding the SQL standard whereever possible.
For that reason, we don't approve non-standard syntax just for reasons of
accessibility. Any non-standard syntax we approve needs to add
significant extra functionality to the DBMS, not just convenience, and
certainly not because MySQL does it.

"Standards are important" is one of the themes of PostgreSQL which
differentiates us from MySQL.

Another reason is that we have more people migrating from MySQL to
Postgre than any other database server. People don't migrate to Postgre
from Oracle. Hardly from MS SQL Server.

You're mistaken. I think we get more migrations from Oracle than from
MySQL. And quite a few from DB2 and Informix.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

--
Atenciosamente,

Rafael Azevedo
.: Diretor
:: WEBPRO SOLUÇÕES DIGITAIS
:: Telefone: 51 3266.3446
:: Celular: 51 9243.9893
:: http://www.webpro.com.br
:: Email: rafael@webpro.com.br
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Conheça o MAILMAN, Solução em E-mail Marketing
:: http://www.mailman.com.br/