Re: [QUESTIONS] is Postgres an SQL-based database? - Mailing list pgsql-hackers

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'