Fixed #21035 -- Changed docs to treat the acronym SQL phonetically.

The documentation and comments now all use 'an' to
refer to the word SQL and not 'a'.

docs/ref/contrib/gis/testing.txt

@@ -33,7 +33,7 @@ database to use. It automatically defaults to ``'template_postgis'``
 ^^^^^^^^^^^^^^^^^^^
 
 When GeoDjango's spatial backend initializes on PostGIS, it has to perform
-a SQL query to determine the version in order to figure out what
+an SQL query to determine the version in order to figure out what
 features are available. Advanced users wishing to prevent this additional
 query may set the version manually using a 3-tuple of integers specifying
 the major, minor, and subminor version numbers for PostGIS. For example,

docs/ref/databases.txt

@@ -635,7 +635,7 @@ Parameters not quoted in ``connection.queries``
 ``sqlite3`` does not provide a way to retrieve the SQL after quoting and
 substituting the parameters. Instead, the SQL in ``connection.queries`` is
 rebuilt with a simple string interpolation. It may be incorrect. Make sure
-you add quotes where necessary before copying a query into a SQLite shell.
+you add quotes where necessary before copying a query into an SQLite shell.
 
 .. _oracle-notes:
 

docs/ref/django-admin.txt

@@ -1519,7 +1519,7 @@ number of roles in which color is used:
 * ``notice`` - A minor error.
 * ``sql_field`` - The name of a model field in SQL.
 * ``sql_coltype`` - The type of a model field in SQL.
-* ``sql_keyword`` - A SQL keyword.
+* ``sql_keyword`` - An SQL keyword.
 * ``sql_table`` - The name of a model in SQL.
 * ``http_info`` - A 1XX HTTP Informational server response.
 * ``http_success`` - A 2XX HTTP Success server response.

docs/ref/models/fields.txt

@@ -1175,7 +1175,7 @@ The possible values for :attr:`~ForeignKey.on_delete` are found in
 
     Take no action. If your database backend enforces referential
     integrity, this will cause an :exc:`~django.db.IntegrityError` unless
-    you manually add a SQL ``ON DELETE`` constraint to the database field
+    you manually add an SQL ``ON DELETE`` constraint to the database field
     (perhaps using :ref:`initial sql<initial-sql>`).
 
 .. _ref-manytomany:

docs/ref/models/instances.txt

@@ -417,7 +417,7 @@ Deleting objects
 
 .. method:: Model.delete([using=DEFAULT_DB_ALIAS])
 
-Issues a SQL ``DELETE`` for the object. This only deletes the object in the
+Issues an SQL ``DELETE`` for the object. This only deletes the object in the
 database; the Python instance will still exist and will still have data in
 its fields.
 

docs/ref/models/querysets.txt

@@ -802,7 +802,7 @@ This has a similar purpose to ``select_related``, in that both are designed to
 stop the deluge of database queries that is caused by accessing related objects,
 but the strategy is quite different.
 
-``select_related`` works by creating a SQL join and including the fields of the
+``select_related`` works by creating an SQL join and including the fields of the
 related object in the ``SELECT`` statement. For this reason, ``select_related``
 gets the related objects in the same database query. However, to avoid the much
 larger result set that would result from joining across a 'many' relationship,
@@ -932,7 +932,7 @@ referenced is needed, rather than one query for all the items. There could be
 additional queries on the ``ContentType`` table if the relevant rows have not
 already been fetched.
 
-``prefetch_related`` in most cases will be implemented using a SQL query that
+``prefetch_related`` in most cases will be implemented using an SQL query that
 uses the 'IN' operator. This means that for a large ``QuerySet`` a large 'IN' clause
 could be generated, which, depending on the database, might have performance
 problems of its own when it comes to parsing or executing the SQL query. Always