5 ms·

I was at Etsy when this was being built by a consultant, ostensibly for us to use to test our morass of stored procedures in perpetuity. Early on, someone got s

I was at Etsy when this was being built by a consultant, ostensibly for us to use to test our morass of stored procedures in perpetuity. Early on, someone got some bad advice and thought you were safe from sql injection if you wrote your sql inside stored procedures. This misconception got wildly out of hand. We stopped writing sprocs and migrated to MySQL over many years instead. I'm happy with the decision. The database isn't a good place to put things that need extensive unit testing. Or at least it isn't if you're a giant consumer-facing website. YMMV.

pyre 11y ago
Why the migration to MySQL rather than just migrating away from the stored procedures?
- mcfunley 11y ago
  We hired some key employees from Flickr who knew a particular MySQL sharding strategy really well. Postgres would have worked fine, just not the way we were using it back then.
elchief 11y ago
Ya PostGIS is dumb and worthless. You should only use your db as a dumb data dump. You shouldn't even bother with keys.
spacemanmatt 11y ago
I'll probably never understand why people believe that a stored proc is not subject to injection attacks. Like they're magic or something.
- thornygreb 11y ago
  Because if you use the input parameters correctly they are immune to injection. If you concatenate unsanitized input you are susceptible no matter where you write the SQL.
  - mateuszf 11y ago
    Though that's also true if it's done application-server side.
    - spacemanmatt 11y ago
      Yup. Examples: value stored in a table is concatenated into a query without escapement, leaving it vulnerable to injection. Whose job was it to ensure the DB contained clean data? My policy has been to call quote_identifier or quote_literal (PostgreSQL) where applicable, or use typecasts to enforce value literals.
  - spacemanmatt 11y ago
    I get that. That is exactly the same condition as sanitizing inputs in every other context of passing parameters to a service/proc/func. I would not phrase immunity to injection conditionally; there is no immunity, only sanitizing inputs.

pyre 11y ago

Why the migration to MySQL rather than just migrating away from the stored procedures?

mcfunley 11y ago
We hired some key employees from Flickr who knew a particular MySQL sharding strategy really well. Postgres would have worked fine, just not the way we were using it back then.

elchief 11y ago

Ya PostGIS is dumb and worthless. You should only use your db as a dumb data dump. You shouldn't even bother with keys.

spacemanmatt 11y ago

I'll probably never understand why people believe that a stored proc is not subject to injection attacks. Like they're magic or something.

thornygreb 11y ago
Because if you use the input parameters correctly they are immune to injection. If you concatenate unsanitized input you are susceptible no matter where you write the SQL.
- mateuszf 11y ago
  Though that's also true if it's done application-server side.
  - spacemanmatt 11y ago
    Yup. Examples: value stored in a table is concatenated into a query without escapement, leaving it vulnerable to injection. Whose job was it to ensure the DB contained clean data? My policy has been to call quote_identifier or quote_literal (PostgreSQL) where applicable, or use typecasts to enforce value literals.
- spacemanmatt 11y ago
  I get that. That is exactly the same condition as sanitizing inputs in every other context of passing parameters to a service/proc/func. I would not phrase immunity to injection conditionally; there is no immunity, only sanitizing inputs.