Re: Opening view that uses a function - empty column - Mailing list pgsql-jdbc

Couple of points - though they won't help the current question probably:

>Brady's original
---------------my responses embedded


> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-
> owner@postgresql.org] On Behalf Of Brady Mathis
> Sent: Monday, July 30, 2012 1:38 PM
> To: pgsql-jdbc@postgresql.org
> Subject: Re: [JDBC] Opening view that uses a function - empty column
>
> Oh!  And, I made another observation while cracking away at this:  When I
> connect to the DB using PGAdmin (1.14.3) from a remote workstation as
> opposed to on the DB server itself, I see the same problem with the empty
> external_id column when executing "select * from rhs.encounter;".

----------------Are you sure that when you connect to the server from
"...the DB server itself" you are connecting to the same database as when
you do so remotely?

----------------This really feels like an identity issue and not anything
specifically related to the code you are showing us.  That said...see below.

>
> Could this be a problem with how I have implemented my functions?  There
> are two  functions calls actually used to fill the column - I included the
> complete text of the functions below.
>
> get_valid_xml - ensures that content from pg_largeobject is valid xml
> extract_from_extended - uses xmlparse and xpath to get one specific value
>
> Thanks...again!
>
> /* Function to validate xml for xpath use in SQL query */ CREATE OR
REPLACE
> FUNCTION rhs.get_valid_xml(x text)
>   RETURNS xml AS
> $BODY$
> BEGIN
>     PERFORM XMLPARSE( DOCUMENT x );
>         RETURN XMLPARSE( DOCUMENT x );

------------It is unnecessary to call XMLPARSE twice, especially since you
are doing so on the "no exception" code path.

>     EXCEPTION WHEN OTHERS THEN
>         RETURN XMLPARSE( DOCUMENT '<?xml version="1.0"
> encoding="UTF-8"?><fields></fields>' ); END; $BODY$


------------Whenever you are having difficulties you should avoid ignoring
exceptions.  At worse perform a RAISE NOTICE when one occurs it you still
want to send back an empty document.  However, raising the exception is also
a valid and useful action.  If you are debugging then raising an exception
(and reviewing it) is even more worthwhile.


>   LANGUAGE plpgsql VOLATILE
>   COST 100;
> ALTER FUNCTION rhs.get_valid_xml(text) OWNER TO postgres;
>
>
> /* Function to allow extract of fields from _extended */ CREATE OR REPLACE
> FUNCTION rhs.extract_from_extended(field_name text, menu_data_id
> bigint)
>   RETURNS text AS
> $BODY$
>     select translate( xpath('//field[@name="'||$1||'" and
> @type="String"]/text()', xmlparse(document ( rhs.get_valid_xml(
> array_to_string( array(select lo.data from app.menu_data md,
> pg_catalog.pg_largeobject lo where md.id = $2 and  md.xml01 = lo.loid),
'') )
> )))::text, '{}', ''); $BODY$


------------Here you call XMLParse/Document on the result of
"get_valid_xml(...)";  this seems redundant since "get_valid_xml(...)"
already does this.


>   LANGUAGE sql VOLATILE
>   COST 100;
> ALTER FUNCTION rhs.extract_from_extended(text, bigint) OWNER TO
> postgres;