User should be able to set the length of the aggregator field e.g. the author field

Fix spelling mistake

Writing correction

This is a writeup for further exploring the issue.
.
One option to solve this could be to increase the value in the database of varchar.

According to the Drupal F.A.Q.:

Why does Drupal need a database? What databases are supported?
Drupal stores its information - the individual pages, the registered users, and so on - in the database. The database forms the back-end for your Drupal site. At this time, Drupal supports MySQL (or an equivalent such as MariaDB), PostgreSQL, and in Drupal 7, SQLite.

Varchar limits of databases:

This list claims in no way to be complete, but as a starting point for a feasibility study.

MySQl version lower than 5.0.3: 255
MySQl version MySQL 5.0.3 and higher: 65,535
PostgresSQL: 10485760(?)
MariaDB: unknown at this time
SQLite: Does not enforce the length of varchar

Other databases Drupal is run on in the wild (there may be more):
Oracle: 4000
MSSQL: 8000

Adding the limit to a form field in Aggregator

Instead of manually setting the limit in the database, what might be a solution is allowing the user with the proper rights to set the limit of the varchar field. This based on the limit of the database.

The Aggegrator field for the author could then say something like this in the case of MySQL:
Author Field Length [ ..Please enter value...] (Max Length = 65,535)

or in the case of Oracle:
Author Field Length [ ..Please enter value...] (Max Length = 4000)

The standard limit value could either be entered manually, or even better would be if it could be asked from the database. So let's say for the sake of illustration that the user enters a value of 1500. This would then set:

Pseudocode

$varchar_limit = 'varchar limit entered in form (1500 in this case)'. 

$item['author'] = truncate_utf8($item['author'], $varchar_limit, TRUE, TRUE);

Temporary solution?

Another question is can the length of the varchar field be manually edited at this point? So for example changing the value of truncate_utf8 through a module as well as changing the varchar field in the database to a larger number (when the database allows for it)? This would allow for a solution where core code would not have to be changed at the moment. Leading to the following point.

How many people will have need of this solution.

The length of the field can be a semantic discussion. Some users may never run into this issue, while others will run into this. From what I can see there are two options at present:

1. That the Aggregator module has a set limit for certain fields and if users need a bigger length they should user another module. Stating this in the documentation leads to clarity, and the user knows the limits of the module. Which in its own right is a good thing.
2. The Aggregator module should account for a larger length, whether through a manual coding adjustment or through an integral solution.

Remaining Questions

1. Should fields in the database be a varchar, text, or something else?
2. Should there be a limit on the field? There are varying viewpoints on this.
3. Which leads to the best performance (out of the box)?
4. How does truncate_utf8 in the Aggregator module work when a feed has another encoding?
5. Would you want to be able to change the limit of the field of truncate_utf8 or the database field from within the application itself, or keep this in a seperate file for example or manually editing settings.php and manually configuring the database?

Other things to consider

Not entirely sure if these need seperate issues in the cue.

1. How many database fields in Drupal use varchar? Are there other issues where setting the value of varchar could be a solution? Should this then be in core or a module?
2. There should be an alert message given/ logged in the backend if the value of a field in the feed exceeds the limit. (At the time of writing I could not find any information on whether Aggregator already does this. Please see the following support request).

Updated issue summary.