Dear Jan,
> > If you want to promote postgreSQL, then it should be good that anything
> > from outside (whether standard or not) can work with postgreSQL, but
> > anything that work in pg may not work outside;-)
>
> I couldn't disagree more. What you are asking for is to do whatever (you
> think) gets the crowds cheering. That is exactly what MySQL attempts by
> stuffing one half baked feature after another into their db product and
> calling it "integration". What we try instead is to create a stable,
> reliable and predictable database server.
Well, I can have different opinions, depending on the standpoint;-)
(1) as a sql developer, I may want to have a tool that helps me write
portable and standard code. Well, if I know there is a standard.
Otherwise, I just want to code, and the more feature the better.
(2) as a product developer, I may want to serve all my customers, whether
they are of the "standard" type or not.
(3) as a product marketer, I may want that my product as distinguishable
features so that I can "sell" it because it does more that the
standard.
I've been involved in a Fortran research compiler, and I assure you
that you must support extensions (sun cray...)
if you want to take real industrial codes.
So on the point that the standard must be supported, I perfectly agree.
On the point that anything else should be dropped out: let's do it!
I'll send a patch to remove all those non portable features in postgresql
that make users write non portable code... But I'm not sure it will be
accepted;-)
Moreover, having == as a synonym for = is not necessarily in contradiction
with a stable, reliable and predictable server.
> AND is not an operator, ...
The docs says "logical operator". Maybe you mean "is not a pg_operator".
--
Fabien Coelho - [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
