> Is Postgres an SQL-based database or SQL is only an option?
Yes.
> I'd uploaded 6.3 and I'm palying with it. Congratulations to Developers
> PostgreSQL is now more SQL92-compliant.
> But I can't understand one thing; seems that Postgres is SQL-based. (PostgreSQL)
> ^^^
> Is there a reason why developers implemnts new functions not SQL-compatible ?
Yes. There is more to SQL and ORDBMS than SQL87/89/92.
> example:
> In this release there's a very useful function LENGTH(), thanks to Thomas.
> but it's not SQL. CHARACTER_LENGTH() or CHAR_LENGTH() this is SQL.
PostgreSQL is an ORDBMS engine with an SQL front end. SQL92, which does not address
the possibility of type extensibility, tends to define type-specific functions,
such as you mention, in a heavy and crude manner. We have other types for which
"length" is an obvious useful quality; why put the type name into the function
name? And why require two forms of the same function for every type??
The real implementation issue is this: for built-in functions, every function call
must currently have a unique name. For generic functions such as length, we define
a second "sql function" with the generic name which then refers to the built-in
unique function name. For character types, we would need two more of these "sql
functions" for each character type. That's four function definitions in pg_proc for
each character type as opposed to the two definitions we currently have.
You raise a good point, however, in that we should provide the SQL92-compatible
function name where possible (I think you have found one of the few cases where we
do not). Perhaps we can translate function names in the parser as we do for type
names? I'll look into it...
> Maybe there's a reason why somebody needs to invent again the wheel but I cannot
> understand it.
We are already working with a round wheel (well, at least ovoid), and are trying to
prevent it from becoming square :)
- Tom
