Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PgTAP: Unit Testing for PostgreSQL

pgtap.org

Post reply on HN
Print view View original

21–22 of 22 posts

Re: PgTAP: Unit Testing for PostgreSQL

#21

Post by spacemanmatt »

mateuszf wrote: post #19
thornygreb wrote: post #18

Earlier quoted context omitted.

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.

Though that's also true if it's done application-server side.

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.

Re: PgTAP: Unit Testing for PostgreSQL

#22

Post by ghufran_syed »

pmontra wrote: post #17
ghufran_syed wrote: post #5

Does the use case for this maybe depend on your application language and testing facilities? We are comfortable writing sql where it offers an advantage over the alternative, but I can't see what benefit PgTAP offers for our situation (but very willing to be persuaded). We have a rails app backed by postgres. We routinely write database migrations in sql (activerecord doesn't seem to offer much advantage here), and w…

I understand enforcing data integrity inside the db (checks, triggers, etc) but, especially if your main client is a Rails application, why are you writing migrations in SQL and not in Ruby? I feel that since the introduction of reversible transformations (the change method) and "native" foreign keys (I had been rolling my own methods before) we get so much for free. Do you write two different scripts for migrating u…

It was a little while ago, but I think it was because we wanted to use foreign keys, and it just seemed easier to do it directly in sql. We also wanted to use some postgres specific types that weren't supported at the time (range types) as well as a custom data type.

I love writing ruby code, but the extra layer of indirection didn't seem to have much benefit to us in terms of time and effort, and we kept running into features that we wanted to use from postgres that we couldn't use from activerecord.

We do write a separate down migration script.

Post reply on HN