[GENERAL] Make "(composite).function_name" syntax work without search_path changes? - Mailing list pgsql-general

From David G. Johnston
Subject [GENERAL] Make "(composite).function_name" syntax work without search_path changes?
Date
Msg-id CAKFQuwasM3oA+A12rHYM0sMa7FU7aAPL2viQLLcViS2PEmZ8WQ@mail.gmail.com
Whole thread Raw
Responses Re: [GENERAL] Make "(composite).function_name" syntax work without search_path changes?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
CREATE SCHEMA altschema;
CREATE TYPE altschema.alttype AS ( altid text, altlabel text );

CREATE FUNCTION altschema.label(item altschema.alttype)
RETURNS text
LANGUAGE sql
AS $$
SELECT (item).altlabel;
$$;

WITH vals (v) AS (
SELECT ('1', 'One')::altschema.alttype
)
SELECT (v).label
FROM vals;

-- column "label" not found in data type altschema.alttype

SET search_path TO altschema;

WITH vals (v) AS (
SELECT ('1', 'One')::altschema.alttype
)
SELECT (v).label
FROM vals;

-- success

The system knows that the datatype being inspected is "altschema.alttype" - would it be reasonable for the system to check for a function named "label" in the same schema as the target type, "altschema", with the target argument type and invoke it if present?

At this point I'm just writing: altschema.label(v) which is adequate but not as clean.  I'm consciously trying to write queries that don't require application schemas in the search path: including the joyous operator(altschema.@@) syntax in some situations.  I suppose inference could be considered in that situation as well.

David J.

pgsql-general by date:

Previous
From: rakeshkumar464
Date:
Subject: Re: [GENERAL] pg_audit to mask literal sql
Next
From: rakeshkumar464
Date:
Subject: [GENERAL] pgaduit - is there a way to audit a role