what do i do with a human being that puts pointers in SQL queries

Pointers as in MEMORY pointers, disk pointers or something like surrealdb pointers?

@melezorus34 this relies on knowing the database and a bit of context.

@darksideofyay
Are you talking about in-memory allocation of variables?

Like...

@a := 1;
SELECT x FROM table WHERE field = @a;

@melezorus34 @C0D4 taking about cursor, which is a type of pointer sql has to read line by line in the database

@darksideofyay I've always made the application layer deal with this, although I'm sure there's a valid use case of having the db do it instead.... but then I'm a... give me what I ask for and I'll sort it out... kind of guy.

In my (and my db professor from collage) cursors are rarely used for tasks other than maintenence and administration.
They are also at least order of magnitude slower than query with cte.

Does that person realize how much worse the performance is with cursor?
Maybe try running a few tests to show them the impact? Especially on larger datasets, i remember seeing about 30s difference in query execution time.

@C0D4 no, i don't think you get it. he's doing row by row instead of a join. the final result is still a big table

@impune-pl this person is not IT. pretty much tells the whole story

@darksideofyay > row by row

you sure the term "human being" is applicable?

I had been programming Python for a while. I originally was programming C++. So I tried to do a lot of things in Python the C++ way. This a bad idea. I finally found a video on youtube that talked about Idiomatic Python. This helped me understand how to more efficiently program Python. There might be a video like that for SQL. Also, showing how it slows down queries would be helpful.

Cursors are the thing in databases that are 95 % used for the wrong reason, 4 % used for a valid reason and correct and 1 % without a doubt necessary and implemented safely and correct.

The most wrong reason for using cursors is memory.

No. Just no. You can do it properly in all non-ancient drivers - use the drivers feature to stream data row by row.

Don't solve it inside the database.

Cause you might cause memory issues by shoving data around in the database by utilizing cursors. Cause memory is needed to generate the temporary representation of data... Which might end bad... Really bad.

That said, any professor still teaching cursors as a go-to way to program SQL should be sent to retirement... Cause it's just the wrong way.

In 7 years of professional development I have used cursors exactly once. And I'm pretty sure it was not even something running in production regularly, just some script for analysis.. Maybe in the 4% @IntrusionCM mentioned.

@IntrusionCM what he was using it for could be solved with a join. it wouldn't be pretty, but it would be much better

@darksideofyay

JOINs are pretty. They're one of the most important things in SQL.

Correctly implementing and utilizing them is one of the hard things to learn, but makes all the difference.