4 ms·

> DBs have overstepped their bounds And they have a stringly typed interface! It sucks! When both the languages inside and outside the database are typed, why

by geon 10y ago

> DBs have overstepped their bounds And they have a stringly typed interface! It sucks! When both the languages inside and outside the database are typed, why should the interface between them not be? It is just unfathomably bad.

majewsky 10y ago
Uh, what? How is this stringly-typed: https://www.postgresql.org/docs/9.4/static/datatype.html https://www.postgresql.org/docs/9.4/static/datatype.html ? Postgres's type system is actually more sophisticated than any programming language that I know. The problem is that ORM developers are much more serious about interoperability than can be reasonably argued, so you cannot rely on much more than VARCHAR, INTEGER and maybe BOOLEAN.
- dpark 10y ago
  Query input to SQL is literally a string. Output is also a string. Thus "stringly typed" interface. Yes, DB storage is strongly typed, but the interface is not. I'm not sure how much an issue this really is, but it's what the GP is talking about.
  - majewsky 10y ago
    So? Data in computers is all 0s an 1s, but you don't see anyone complaining about bitly-typed languages. Strong typing refers to the presence of type context wherever a value is used, not to the wire protocol.
    - geon 10y ago
      The data you get out of the database will be untyped. When the language in the database is typed (SQL) and the language outside is typed too (c#, typescript, etc), it would be nice to keep that type information. An ORM doesn't count since it is just a bad attemot to work around the inherent problems with SQL as an interface.
      - anarazel 10y ago
        > The data you get out of the database will be untyped. Uh, no. Nearly all database access protocols maintain type information for the resultsets returned to the client. That's definitely the case for postgres (cf. RowDescription in https://www.postgresql.org/docs/devel/static/protocol-message-formats.html https://www.postgresql.org/docs/devel/static/protocol-messag... , accessible to the provided client library via PQftype,cf. https://www.postgresql.org/docs/devel/static/libpq-exec.html#libpq-exec-select-info https://www.postgresql.org/docs/devel/static/libpq-exec.html... ) There's plenty cases to be made against RDBMs. No need to invent more.

by geon 10y ago

majewsky 10y ago

Uh, what? How is this stringly-typed: https://www.postgresql.org/docs/9.4/static/datatype.html https://www.postgresql.org/docs/9.4/static/datatype.html ? Postgres's type system is actually more sophisticated than any programming language that I know. The problem is that ORM developers are much more serious about interoperability than can be reasonably argued, so you cannot rely on much more than VARCHAR, INTEGER and maybe BOOLEAN.

dpark 10y ago
Query input to SQL is literally a string. Output is also a string. Thus "stringly typed" interface. Yes, DB storage is strongly typed, but the interface is not. I'm not sure how much an issue this really is, but it's what the GP is talking about.
- majewsky 10y ago
  So? Data in computers is all 0s an 1s, but you don't see anyone complaining about bitly-typed languages. Strong typing refers to the presence of type context wherever a value is used, not to the wire protocol.
  - geon 10y ago
    The data you get out of the database will be untyped. When the language in the database is typed (SQL) and the language outside is typed too (c#, typescript, etc), it would be nice to keep that type information. An ORM doesn't count since it is just a bad attemot to work around the inherent problems with SQL as an interface.
    - anarazel 10y ago
      > The data you get out of the database will be untyped. Uh, no. Nearly all database access protocols maintain type information for the resultsets returned to the client. That's definitely the case for postgres (cf. RowDescription in https://www.postgresql.org/docs/devel/static/protocol-message-formats.html https://www.postgresql.org/docs/devel/static/protocol-messag... , accessible to the provided client library via PQftype,cf. https://www.postgresql.org/docs/devel/static/libpq-exec.html#libpq-exec-select-info https://www.postgresql.org/docs/devel/static/libpq-exec.html... ) There's plenty cases to be made against RDBMs. No need to invent more.