Re: psql: add \pset true/false - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: psql: add \pset true/false
Date
Msg-id ef6da9d0-f97a-4a83-9785-c8c31992d27c@mm
Whole thread Raw
In response to Re: psql: add \pset true/false  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
    Jim Nasby wrote:

> I was more thinking it would be nice to be able to temporarily
> over-ride/wrap what an output function is doing. AFAIK that would allow
> this to work everywhere (row(), copy, etc). I don't know of any remotely
> practical way to do that, though.

Yes. Something like:

SET [LOCAL] OUTPUT STYLE FOR  TYPE "typename" TO json_value;

where json_value would represent a set of type-dependant
parameters.
Then the type's output_function and type_modifier_output_function
refered to in CREATE TYPE could use these parameters
to customize the text representation.

For example:
SET output style FOR TYPE bool TO '{"true":"t", "false":"f"}';
or
SET output style FOR TYPE bool TO '{"true":"TRUE", "false":"FALSE"}';

This style declaration doesn't quite fit with GUCs because it should
be bound to a type, but otherwise the behavior is comparable to a
session-wide or transaction-wide SET.

Could be used for date/times too:

SET output style FOR TYPE timestamptz TO  '{"format": "DD/MM/YYYY HH24:MI TZ"}';

where applying format would essentially mean
to_char(timestamp, format), which is more flexible
than DateStyle for the output part.


Going even further, maybe some types could support:
SET output style FOR TYPE typename TO  '{"function": "funcname"}';

where the function should exist as funcname(typename) returns text
and the type's output_function would just act as a wrapper.

or even:
SET output style FOR TYPE typename TO  '{"filter": "funcname"}';
where the function would exist as funcname(text) returns text
and the type's output_function would call funcname
as an output filter for values already in text format.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Confusing results with lateral references
Next
From: Amit Langote
Date:
Subject: Re: Passing initially_valid values instead of !skip_validation to StoreRelCheck() in AddRelationNewConstraints()