4 ms·
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.
by 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 agoSo? 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 agoThe 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.