From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: format() changes discussion (was: Re: psql metaqueries with \gexec) |
Date: | 2016-02-23 01:32:14 |
Message-ID: | 56CBB69E.4040305@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/22/16 5:16 PM, Corey Huinker wrote:
> (One thing I had to come up with was processing of arrays, which you
> also see in that example JSON -- it's the specifiers that have a colon
> inside the {}. The part after the colon is used as separator between
> the array elements, and each element is expanded separately.)
>
>
> I'm splitting the subject line because it seems like two very different
> patches may come out of this.
Oops. Just saw this.
I don't think it'd make sense to make format() itself as capable as what
Alvaro did for event triggers. Something that geared towards dealing
with catalog objects should be it's own thing.
What would be very useful IMHO is a version of format() that accepted
hstore as it's second argument and then let you use names in the format
specification. IE:
format( 'blahblah name1%I blahblah literal_a%L blah "some string"%s'
, 'name1 => name, literal_a => a, "some string" => string
)
I suggest hstore over json because it's easier to work with by hand than
json is, and there's no ambiguity with things like objects or arrays.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-02-23 01:52:08 | Re: Writing new unit tests with PostgresNode |
Previous Message | Jim Nasby | 2016-02-23 01:23:08 | Re: psql metaqueries with \gexec |