2 edited body
source | link

The question is specifically whether adding an arbitrary length limit to VARCHAR columns?

To that, the answer is simply "no". There is nothing that can justify adding an arbitrary limit like you would in inferior databases that support varchar(max) or use conventions like varchar(255). However, if the spec addresses a limit, I think the answer becomes much more complex especially on modern versions of PostgreSQL. And, for that, I would lean towards YES.

In my opinion, the limit is a wise-choice if the spec requires it. Especially for more reasonable workloads. If for no other reason then to preserve meta-data.

FormFrom my answer here, index performance for CHAR vs VARCHAR (Postgres), where I address the value of meta-data.

If I found a spec that had variable-length text-keys that were meaningful and that I trusted to have a constant max-length, I would use varchar too. However, I can't think of anything that fits that criteria.

That about sums up my sentiments.

The question is specifically whether adding an arbitrary length limit to VARCHAR columns?

To that, the answer is simply "no". There is nothing that can justify adding an arbitrary limit like you would in inferior databases that support varchar(max) or use conventions like varchar(255). However, if the spec addresses a limit, I think the answer becomes much more complex especially on modern versions of PostgreSQL. And, for that, I would lean towards YES.

In my opinion, the limit is a wise-choice if the spec requires it. Especially for more reasonable workloads. If for no other reason then to preserve meta-data.

Form my answer here, index performance for CHAR vs VARCHAR (Postgres), where I address the value of meta-data.

If I found a spec that had variable-length text-keys that were meaningful and that I trusted to have a constant max-length, I would use varchar too. However, I can't think of anything that fits that criteria.

That about sums up my sentiments.

The question is specifically whether adding an arbitrary length limit to VARCHAR columns?

To that, the answer is simply "no". There is nothing that can justify adding an arbitrary limit like you would in inferior databases that support varchar(max) or use conventions like varchar(255). However, if the spec addresses a limit, I think the answer becomes much more complex especially on modern versions of PostgreSQL. And, for that, I would lean towards YES.

In my opinion, the limit is a wise-choice if the spec requires it. Especially for more reasonable workloads. If for no other reason then to preserve meta-data.

From my answer here, index performance for CHAR vs VARCHAR (Postgres), where I address the value of meta-data.

If I found a spec that had variable-length text-keys that were meaningful and that I trusted to have a constant max-length, I would use varchar too. However, I can't think of anything that fits that criteria.

1
source | link

The question is specifically whether adding an arbitrary length limit to VARCHAR columns?

To that, the answer is simply "no". There is nothing that can justify adding an arbitrary limit like you would in inferior databases that support varchar(max) or use conventions like varchar(255). However, if the spec addresses a limit, I think the answer becomes much more complex especially on modern versions of PostgreSQL. And, for that, I would lean towards YES.

In my opinion, the limit is a wise-choice if the spec requires it. Especially for more reasonable workloads. If for no other reason then to preserve meta-data.

Form my answer here, index performance for CHAR vs VARCHAR (Postgres), where I address the value of meta-data.

If I found a spec that had variable-length text-keys that were meaningful and that I trusted to have a constant max-length, I would use varchar too. However, I can't think of anything that fits that criteria.

That about sums up my sentiments.