Context Navigation

Changes between Version 1 and Version 2 of Ticket #25705, comment 15

v1	v2
12	12	> We absolutely don't want to support this pattern in a context where we can't guarantee that the proper quoting is performed on all supported backends as that might result in SQL injection problems. In this sense I think that it's a good thing that `sql.Query.__str__` doesn't attempt to perform the proper quoting to make it clear it should not be used for this purpose.
13	13
14		I'm not sure I understand your point. I think the original commenter was suggesting that just as a simple (and probably not ideal) way to do the test. I wouldn't consider someone doing `str(qs.query)` to then pass in to `raw()` a real use case that anyone would do.
	14	I'm not sure I understand your point. I think the original commenter was suggesting that just as a simple (and probably not ideal) way to do the test. I wouldn't consider someone doing `str(qs.query)` to then pass in to `raw()` (which the docs already warn of SQL injections) a real use case that anyone would do.
15	15	Personally, the use case I've had with this issue is printing the query to then try to format it and maybe execute it in a sql editor connected that my database while testing stuff in local. For that case your suggestion of sql_with_params wouldn't cover it. I'm not against having that method either, but I don't see it as a replacement of a correct`str(qs.query)`.
16	16