Re: SQL feature requests
От | Chuck McDevitt |
---|---|
Тема | Re: SQL feature requests |
Дата | |
Msg-id | EB48EBF3B239E948AC1E3F3780CF8F880277B29B@MI8NYCMAIL02.Mi8.com обсуждение исходный текст |
Ответ на | Re: SQL feature requests (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: SQL feature requests
Re: SQL feature requests |
Список | pgsql-hackers |
> -----Original Message----- > From: Andrew Dunstan [mailto:andrew@dunslane.net] > Sent: Thursday, August 23, 2007 10:26 AM > To: Chuck McDevitt > Cc: Tom Lane; Gregory Stark; Michael Glaesemann; Ben Tilly; pgsql- > hackers@postgresql.org > Subject: Re: [HACKERS] SQL feature requests > > > > Chuck McDevitt wrote: > > Sometimes supporting "de-facto" standards as well as official > standards > > makes sense. > > > > > > > > On that basis we would support huge pieces of stuff that emulates MySQL > too. Or perhaps you'd like us to follow Oracle's treatment of NULL. Who > gets to choose what is the de facto standard we follow? > > cheers > > Andrew You must be joking... PostgreSQL already has a huge amount of "non-standard" syntax and semantics (perhaps "extensions" is a better word?). Everything from non-standard cast operator, non-standard substr, non-standard trim, non standard group by semantics (allowing simple ints to mean column number)... Given a day, we could probably write down several pages of "non-standard" features of PGSQL. Who decides what de facto standards to support, and which not? The PostgreSQL community of course. In general, we wouldn't want to support any de facto standard that: 1. Is supported only by one vendor 2. Causes any standard SQL statement to fail, or return a different answer from the standard. The proposed change doesn't fail either of these.
В списке pgsql-hackers по дате отправления: