Re: SET variables

At 12:45 PM 5/13/01 -0400, mlw wrote:

>A Postgres with enough Oracle-isms would be a world beater.

No doubt. I'm not as extremist as Philip Greenspun has been in the past
regarding how far PG should go in implementing Oracle-isms, though. His
stated opinion in the past was that PG should implement Oracle's wretched
date arithmetic (which he recognizes is wretched) rather than stick with
SQL92 date and timestamp types (which he recognizes is superior). I'd
oppose that.

So "oracle-isms" should be inspected for merit, that's for sure. The
inclusion of "to_char" and friends not only helped people port from Oracle
to PG but is useful on its own.

I'd put both BIND vars and the enhanced types in parameter lists (which
we already have in PL/pgSQL var decls) in that class.

There are a lot of other features I'd question, though. "CONNECT BY" is
difficult to work around because there's no simplistic way to implement
hierarchical queries in straight SQL92, but the solutions in SQL92 tend
to scale a lot better and be more general. So I'd argue against putting
much effort into "CONNECT BY", or at least putting it at a high priority,
which would probably put me at odds with quite a few Oracle users.

>Postgres would be incredible. As it is, it is a great database. If it could
>have features which make Oracle people comfortable it would be a very serious
>alternative to Oracle. Companies like Greatbridge and PostgreSQL inc. would
>have a much easier sell.

There are actually very few gratuitous features in Oracle - the company's
very, very customer driven. Most of the really horrible differences from
standard SQL92 - date arithmetic, empty string is the same as NULL in DML
statements - are there for historical reasons, i.e. they predate SQL
standardization and Oracle's found it self locked-in/boxed-in by acres of
existing customer code.

- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.