I dunno. I preferred the SQL-89 syntax.
SQL language proposal: JOIN FOREIGN
71–80 of 206 posts
Re: SQL language proposal: JOIN FOREIGN
#72Earlier quoted context omitted.
FWIW we do have `NATURAL JOIN` already, which is a lot worse than this proposal.
NATURAL JOIN is great because it's like a relational AND. How else will you join with Table Dee and Table Dum? https://twitter.com/benjiweber/status/1476629550608101384 It's just risky if you don't design your schema with relational algebra in mind.
I'm 20 years I have never seen anyone use relational algebra. schemas have to be self documenting albeit only in the real world.
Re: SQL language proposal: JOIN FOREIGN
#73What I really need is something like: SELECT -col1, -col14 FROM table LIMIT 50; Where the minus sign means I don't want these two columns. I still don't see a way to do it easily (for Vertica and in Datagrip).
That's very close to SELECT *, which has it's own dangers. I agree that it would be nice for exploration and testing, but probably should not be used in production.
What dangers lay in select *...? Too much data?
Re: SQL language proposal: JOIN FOREIGN
#74Earlier quoted context omitted.
I'm a small PostgreSQL contributor since 2010 myself. I probably can't write the whole patch myself, but if there is enough interest, and if we can work out the details and address the problems raised in this thread and elsewhere, I'm pretty confident we can do it. If we ever get there, the next step would be a reference implementation, probably in PostgreSQL, or to discuss a proposal in the SQL committee.
I'm often interested into what goes into changes to committee-driven standards. To an outsider, proposing a change seems to require one to be part of a shady cabal of Big-5 employees, skilled in the art of hiding subtle, privacy-invading features into inscrutable, plain-text RFCs. That or subjecting yourself to 30K+ what-abouters who deform your suggestion into something unrecognisable. It's refreshing to see a strai…
> To an outsider, proposing a change seems to require one to be part of a shady cabal of Big-5 employees, skilled in the art of hiding subtle, privacy-invading features into inscrutable, plain-text RFCs.
I thought so too. Initially I just tried to get in contact with someone at the Swedish Institute for Standards (SIS), to see if it would be possible to send a proposal to someone in the SQL committee, which I thought was nearly impossible to become a member of. But as it turns out, SIS explained I could actually join the Swedish working group, and participate directly there, I just had to send in an application and get the approval from my employer, since there is a cost involved and you have to be a member via a company. Turns out ISO is a very open and democratic organization, just like Hacker News! :)
I think this proposal could take years until it land, if it ever does, in some form, if concerns can be addressed, but SQL is here to stay for a while, so that doesn't scare me.
Re: SQL language proposal: JOIN FOREIGN
#75What I really need is something like: SELECT -col1, -col14 FROM table LIMIT 50; Where the minus sign means I don't want these two columns. I still don't see a way to do it easily (for Vertica and in Datagrip).
i would rather it written as SELECT * BUT or SELECT * EXCEPT or even SELECT ALL BUT.
SQL has always been that language that is easy to read. even when you don't understand what the queries are doing. adding a cryptic syntax like "-column" would make it less readable.
Re: SQL language proposal: JOIN FOREIGN
#76Earlier quoted context omitted.
I'm a small PostgreSQL contributor since 2010 myself. I probably can't write the whole patch myself, but if there is enough interest, and if we can work out the details and address the problems raised in this thread and elsewhere, I'm pretty confident we can do it. If we ever get there, the next step would be a reference implementation, probably in PostgreSQL, or to discuss a proposal in the SQL committee.
I'm often interested into what goes into changes to committee-driven standards. To an outsider, proposing a change seems to require one to be part of a shady cabal of Big-5 employees, skilled in the art of hiding subtle, privacy-invading features into inscrutable, plain-text RFCs. That or subjecting yourself to 30K+ what-abouters who deform your suggestion into something unrecognisable. It's refreshing to see a strai…
> It's refreshing to see a straightforward, well-formatted proposal (even if I do slightly prefer the `FROM table1 x JOIN table2 y ON x.fk` syntax suggested in other comments).
Thank you! /me feeling happy
Re: SQL language proposal: JOIN FOREIGN
#77What I really need is something like: SELECT -col1, -col14 FROM table LIMIT 50; Where the minus sign means I don't want these two columns. I still don't see a way to do it easily (for Vertica and in Datagrip).
i would rather it written as SELECT * BUT or SELECT * EXCEPT or even SELECT ALL BUT. SQL has always been that language that is easy to read. even when you don't understand what the queries are doing. adding a cryptic syntax like "-column" would make it less readable.
EXCEPT is already a sql keyword
Re: SQL language proposal: JOIN FOREIGN
#78Is this not something that should be written at the app level rather than dml?
Re: SQL language proposal: JOIN FOREIGN
#79It might be just me, but I feel like remembering the foreign key name is more difficult than remembering the columns that you need in the ON clause. Especially since you can usually find the column names by just seeing the data in the table (select * from x) wheres seeing the foreign key names is much harder (show create table x?).
Also, if you use an ORM it will usually generate foreign key names that are almost impossible to remember.
Re: SQL language proposal: JOIN FOREIGN
#80This feels like adding syntactic sugar in some sense. That is, a layer of convenience to accomplish something that can already be accomplished today.
It also breaks the following:
* It's better to be explicit than infer * Keep specifications simple