ST_GeomFromText

What is ST_GeomFromText?

ST_GeomFromText parses a WKT string and returns a PostGIS geometry value. It is the most commonly used text-based geometry constructor.

1ST_GeomFromText(text WKT) → geometry
2ST_GeomFromText(text WKT, integer srid) → geometry

Without an SRID argument, the output SRID is 0 — a common source of confusion in spatial queries. Always supply an SRID unless you know the downstream code handles untagged geometry.

When would you use ST_GeomFromText?

Use ST_GeomFromText for ad-hoc geometry construction in SQL — insert statements from configuration files, literal values in test fixtures, or translating WKT from external APIs into PostGIS storage. It is also widely used to define the bounds of search queries: ST_GeomFromText('POLYGON(...)', 4326).

In migrations from non-spatial databases, the pattern ST_GeomFromText(wkt_text_col, 4326) converts plain text columns to a spatial geometry column.

FAQs

What SRID is used if I omit the second argument?

Zero — meaning "undefined". Spatial queries comparing such geometry to SRID-tagged rows will fail with a "mixed SRID" error. Always supply the second argument unless you are sure SRID-0 is intended.

How is ST_GeomFromText different from ST_GeomFromEWKT?

ST_GeomFromText parses OGC WKT and requires a separate SRID argument. ST_GeomFromEWKT parses PostGIS-extended WKT which embeds the SRID inline (SRID=4326;POINT(0 0)).

Can it parse Z and M coordinates?

In PostGIS, yes — it accepts POINT Z (x y z) or POINT ZM (x y z m) extensions. Strict OGC WKT 1.2 does not require this, but PostGIS tolerates it.

Is it faster than ST_PointFromText / ST_LineFromText?

About the same. The typed constructors add a type check and reject wrong geometry types, giving better error reporting but equivalent performance.