On Mon, Feb 27, 2006 at 12:25:57AM +0300, Nikolay Samokhvalov wrote:
Please help.
how?
...
PostgreSQL has very-very good documentation, but it teaches to
go Pg's way, which is not right in that sense, unfortunately...
By supplying documentation patches, perhaps ?
Karsten
--
GPG key ID
Am Sonntag, 26. Februar 2006 21:24 schrieb Neil Conway:
I think a better approach would be to introduce the concept of SQL
dialects, similar to --std=... in GCC or SQL modes in MySQL 5. That
would help people who want to write standard-compliant applications
while not inconveniencing those who
On 2/27/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Sonntag, 26. Februar 2006 21:24 schrieb Neil Conway:
I think a better approach would be to introduce the concept of SQL
dialects, similar to --std=... in GCC or SQL modes in MySQL 5. That
would help people who want to write
On 2/27/06, Bruno Wolff III [EMAIL PROTECTED] wrote:
The alternatives to distinct on are painful. They are generally both harder
to read and run slower.
'DISTINCT ON' is evil constuction, because (w/o any 'ORDER BY') it
produses unpredictable result, as 'ORDER BY random()' does.
When newbie
On Mon, 27 Feb 2006, Nikolay Samokhvalov wrote:
On 2/27/06, Bruno Wolff III [EMAIL PROTECTED] wrote:
The alternatives to distinct on are painful. They are generally both harder
to read and run slower.
'DISTINCT ON' is evil constuction, because (w/o any 'ORDER BY') it
produses unpredictable
On 2/27/06, Stephan Szabo [EMAIL PROTECTED] wrote:
On Mon, 27 Feb 2006, Nikolay Samokhvalov wrote:
On 2/27/06, Bruno Wolff III [EMAIL PROTECTED] wrote:
The alternatives to distinct on are painful. They are generally both harder
to read and run slower.
'DISTINCT ON' is evil
On Mon, Feb 27, 2006 at 06:26:02PM +0300, Nikolay Samokhvalov wrote:
On 2/27/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Such a thing has been discussed from time to time but in reality you
wouldn't
get useful results from it because just about any application will violate
the standard
On 2/27/06, Martijn van Oosterhout kleptog@svana.org wrote:
Huh? We should ofcourse try to implement SQL:2003 wherever we can, but
to say this means we need to throw out anything not mentioned is silly.
For example, CREATE INDEX is not in SQL:2003, are you seriously
suggesting we remove it?
i
On Mon, Feb 27, 2006 at 06:59:21PM +0300, Nikolay Samokhvalov wrote:
On 2/27/06, Stephan Szabo [EMAIL PROTECTED] wrote:
'DISTINCT ON' is evil constuction, because (w/o any 'ORDER BY') it
produses unpredictable result, as 'ORDER BY random()' does.
And so does UNION in the standard under
On Mon, 27 Feb 2006, Nikolay Samokhvalov wrote:
it's completely different thing. look at the spec and you'll
understand the difference. in two words, with 'DISTINCT ON' we lose
some values (from some columns), when UNION not (it just removes
duplicates, comparing _entire_ rows).
No it's not,
On Mon, Feb 27, 2006 at 18:34:16 +0300,
Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
On 2/27/06, Bruno Wolff III [EMAIL PROTECTED] wrote:
The alternatives to distinct on are painful. They are generally both harder
to read and run slower.
'DISTINCT ON' is evil constuction, because (w/o
On 02/26/2006-10:36AM, Andrus Moor wrote:
It is difficult to write standard-compliant code in Postgres.
There are a lot of constructs which have SQL equivalents but are still used
widely, even in samples in docs!
For example, there are suggestions using
now()::CHAR!=foo
while the
Aren't you afraid of that in the future these people will
switch to MySQL because of ability to work in standard way?..
You're joking, right? At least I had a good laugh.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please
It is difficult to write standard-compliant code in Postgres.
There are a lot of constructs which have SQL equivalents but are still used
widely, even in samples in docs!
For example, there are suggestions using
now()::CHAR!=foo
while the correct way is
CAST(CURRENT_DATE AS CHAR)foo
now()
As long as the SQL standard is supported, support for the ancient syntax
shouldn't be removed - at least not without a very long period of transition.
Do you have any idea how many applications the removal of something simple
like the cast operator :: will break?
It's not difficult to write
Andrus Moor [EMAIL PROTECTED] writes:
For example, there are suggestions using
now()::CHAR!=foo
while the correct way is
CAST(CURRENT_DATE AS CHAR)foo
now() function, :: and != operators should be removed from language.
Your second example requires twice as much typing as your first;
is
On Sun, Feb 26, 2006 at 10:36:23AM +0200, Andrus Moor wrote:
It is difficult to write standard-compliant code in Postgres.
There are a lot of constructs which have SQL equivalents but are still used
widely, even in samples in docs!
For example, there are suggestions using
...
Bruce seems
On Sun, 2006-02-26 at 12:08 -0500, Tom Lane wrote:
We'd consider removing these features if they were actually blocking
support of some spec-required behavior ... but since they don't, it's
quite unlikely they'll ever be removed.
Right; there are plenty of places in which PostgreSQL extends
On 2/26/06, Karsten Hilbert [EMAIL PROTECTED] wrote:
Please help.
how?
is there any place where postgres' SQL:2003 incompatibilities are
being discussed?
I really want to have standard-compatible PostgreSQL and some option
in postgresql.conf that would allow me to restrict Postgres' SQL
syntax
Nikolay Samokhvalov wrote:
On 2/26/06, Karsten Hilbert [EMAIL PROTECTED] wrote:
Please help.
how?
1. Pick an item on the list.
2. Join the -hackers list and ask for info on where to start and discuss
what you want to change.
3. Start coding.
--
Postgresql php tutorials
On Mon, Feb 27, 2006 at 00:25:57 +0300,
Nikolay Samokhvalov [EMAIL PROTECTED] wrote:
On 2/26/06, Karsten Hilbert [EMAIL PROTECTED] wrote:
past'. Yes, standard is 'talkative', but I prefer only standard
things, because it helps me to understand other databases and
'academical things'.
21 matches
Mail list logo
