FIX: PG::StringDataRightTruncation when linking posts (PR #13134)

GitHub

What would happen if we used the slugless topic URL when the URL is too long?

What would happen if we used the slugless topic URL when the URL is too long?

At first glance, this should work just fine. I’ll investigate more to make sure we won’t break anything if we decide to go this way.

But, what a bit concerns me is that by doing this we’ll introduce a new logic just to support a constraint in the database.

if (longer_than_500_chars) {
    use_slugless_link()
} else {
    use_full_link()
}

At the same time, it seems to be safe just to drop constraint. Do we have reasons to have this constraint in the db?

I was just being curious. We could even always use the slugless URL when they’re using encoded slugs.

I’m curious, do we have reasons to have this constraint in the db?

Not sure, probably worth looking at git blame to see if there was a reason in the commit message.

Maybe it was just to ensure there’s some kind of limit on the field in order to avoid it being abused (if that’s even possible).

I say we merge this as is for now, the DB constraint is just causing problems.

@ZogStriP about the initial reason for this constraint, it exists from the initial commit, so as you said it probably was protection from abuse. Now, it’s safe to delete it.

I’m merging this, but I still want to research pros and cons of using slugless URLs for reflection links, so I’m adding it to my list with low priority.

This pull request has been mentioned on Discourse Meta. There might be relevant details there: