Postgres data type for storing Stripe IDs?

[Chris Tsongas]

I'm new to both Postgres and Stripe, wondering if Stripe IDs should be stored as varchar 255 or something else?

[Remi J.]

Hey Chris,

That should work yes! Our API upgrades documentation covers this here [1]:

"You can safely assume object IDs we generate will never exceed 255 characters, but you should be able to handle IDs of up to that length. If for example you’re using MySQL, you should store IDs in a VARCHAR(255) COLLATE utf8_bin column (the COLLATE configuration ensures case-sensitivity in lookups)."

Hope this helps!

Remi

[1] https://stripe.com/docs/upgrades#what-changes-does-stripe-consider-to-be-backwards-compatible

On Wed, Jul 18, 2018 at 2:26 PM, Chris Tsongas <chris....@gmail.com> wrote:

I'm new to both Postgres and Stripe, wondering if Stripe IDs should be stored as varchar 255 or something else?

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

[Yves Berquin]

Hello Chris,

Small comment about your question: in postgreSQL there's no internal difference between varchar(n) and text so you should use text everywhere and not worry about these sizes issues anymore.

See for example here:

https://stackoverflow.com/questions/4848964/postgresql-difference-between-text-and-varchar-character-varying

NOTE: this is probably not the case if you ever want to have your code being compatible with something else than postgreSQL.

Yves

[Brandur Leach]

+1 that `TEXT` and `VARCHAR` get the same implementation in

Postgres.

In my opinion though: I'd still tend to prefer the

`VARCHAR` (or `TEXT` column with a `CHECK` constraint on

length) over unbounded `TEXT`. Limiting the length isn't

strictly required, but it's still useful for protecting

your data's integrity against unexpected input. Say for

example there was an application bug that accidentally

inserted a bad value into the column.

Constraints (be it data types, `CHECK`s, or foreign keys)

are one of the powerful features that Postgres and other

RDMSes offer you compared to "NoSQL", and they're a great

tool for adding a secondary layer of protection against

bugs that would otherwise compromise the shape of your

data. Very often, the more of them you have, the better.

Brandur

--