Re: [QUESTIONS] is Postgres an SQL-based database?

On Wed, 4 Feb 1998, Thomas G. Lockhart wrote:

> > 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.

I agree with you Tom, PostgreSQL should be more than standard,
but users expect that PostgreSQL at least supports SQL syntax.
I agree with you if you talk about implement functions not supported by SQL
but I can't understand if you write the same function with another syntax.
PostgreSQL has many functions that doesn't follow SQL-standard syntax.
I can understand this:

ROLLBACK [ WORK ] -- SQL-syntax
rollback [transaction|work] -- PostgreSQL-syntax (this is more than standard)

and

ALTER TABLE <class_name> ADD [COLUMN] <attr> <type>; --SQL
alter table <class_name> [*] add column <attr> <type>; --PostgreSQL

In this case [*] show that PostgreSQL is an ORDBMS,
but what about keyword COLUMN? It sould be optional.

but I can't understand things like:

\connect <dbname|-> <user> --PostgreSQL
insted of:
CONNECT TO { DEFAULT | <SQL-server name> --SQL
[ AS <connection name> ]
[ USER <user name> ] }
or

CAST expression AS data-type --PostgreSQL
insted of:
CAST ( expression AS { data-type | domain } ) --SQL

>
> > 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.

Ok. That's a good reason. Thanks for your explanation. I understand now.

>
> 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...
Great!
>
> > 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 :)
>
Ok, you are doing an excellent work. Thanks for this great Database.

Ciao, Jose'