Inconsistent PostgreSQL behavior with strings and network functions - postgresql

Question

PostgreSQL's inet functions generally accept strings in correct inet form:
mydb=# select network('10.1.2.3/24');
network
-------------
10.1.2.0/24
(1 row)
However, if string concatenation is used to construct the string, the same function will fail:
mydb=# select network('10.1.2.3' || '/24');
ERROR: function network(text) does not exist
LINE 1: select network('10.1.2.3' || '/24');
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
even though the two strings appear to be equivalent:
mydb=# select '10.1.2.3/24';
?column?
-------------
10.1.2.3/24
(1 row)
mydb=# select '10.1.2.3' || '/24';
?column?
-------------
10.1.2.3/24
(1 row)
You can work around this by casting the concatenated string to inet:
mydb=# select network(('10.1.2.3' || '/24')::inet);
network
-------------
10.1.2.0/24
(1 row)
Can anyone describe this behavior in a way that will help me understand why it happens? Is there implicit casting of whole strings that doesn't affect concatenated strings?

Answer 1

Strictly speaking, a quoted literal in PostgreSQL (e.g. '10.1.2.3/24') is not a string, it is a literal of some type to be determined by the parser.
You can tell the parser what type it is using SQL-standard prefix notation (inet '10.1.2.3/24') or Postgres suffix-cast notation ('10.1.2.3/24'::inet). These are not type-casts, they are the input specification for the particular type. If you don't specify the type, the parser will try to guess at its type based on context, and fall back to the pseudo-type unknown.
When you run network('10.1.2.3/24'), the literal is deduced to be of type inet, because there is only one function called network, and that is the type it expects. The value is never of type text, so no cast is needed.
But when you write network('10.1.2.3' || '/24'), the || operator needs to be resolved first; to do this, Postgres determines (correctly) that the literals '10.1.2.3' and '/24' should be treated as type text, and the result of concatenating them is also text. It then looks for a function called network() which takes a text parameter and doesn't find one; it has no automatic cast configured text to inet, so it fails with a type-checking error.
You can actually see this in action by creating a new function called network that takes a float parameter:
create function network(float) returns text language sql as $$ select 'test'::text; $$
Running select network('10.1.2.3/24') with this function in scope will give you an error "Could not choose a best candidate function", because Postgres doesn't know whether inet or float is the type you intended with your literal '10.1.2.3/24'. (If you create a function network(text), it will be preferred over both; not because the literal is of type text, just because it is considered a "better candidate".)
Conversely, if you specify Select network(text '10.1.2.3/24'), you will get a type error, not an implicit cast.

Answer 2

There seems to be an implicit type cast to inet before applying the network function. This doesn't work when you are explicitly creating a text object by concatenating. You should add an explicit inet type cast:
db=# select network(('10.1.2.3'||'/24')::inet);
network
-------------
10.1.2.0/24
(1 row)