Re: New developer TODO suggestions - Mailing list pgsql-hackers

On Tue, Jun 24, 2014 at 10:58:54AM +0800, Craig Ringer wrote:
> Hi all
> 
> Someone recently mentioned that there's no generate_series(numeric,
> numeric, numeric) .
> 
> That strikes me as a great candidate for a
> new-developer-learning-PostgreSQL TODO.
> 
> 
> A couple of other things I occasionally run into that'd fit the bill:
> 
> * A user-level elog(...) / ereport(...) function callable from SQL.
> Useful in CASE statements.
> 
> * A log_ option to log whenever pg switches to a new xlog segment.

The above seem good.

> 
> * A 'hex' option to 'decode' that decodes regular hex into bytea, or an
> equivalent decode_hex / hex_decode . That's for plain undecorated hex,
> not \x literals.
> 
> * A corresponding encode_hex or hex_encode to emit hex 'text' without \x
> prefix (not a bytea literal)
> 
> (Yes, I know you can form bytea literals with concatenation and decode
> that way, and can strip the \x prefix from a literal on output, but it's
> often pretty awkward).

Uh, don't our SQL string function allow removal of \x?

> * A user-accessible function to decode unicode escapes like \U1011 in
> strings.

Makes sense.

> * A function that converts a json array to a PostgreSQL array of a given
> type if all json members are compatible with the type
> 
> * Expanding the set of json/jsonb operations to introduce features that
> people are used to from jquery, mongo, etc.
> Replace-key-if-exists-without-adding, add-or-replace-key, etc.
> 
> * (not really Pg proper, but enough users run into this that I think we
> should encourage interested people to tackle it): In PgAdmin-III either
> support \copy, \c, etc or detect their use and emit an informative error
> telling the user to use 'psql'.

I think you have to ask Andrew on these.

> * When a user tries to run "psql -f some_custom_format_backup", detect
> this and emit a useful error message. Ditto stdin.

Uh, good idea, but can we really do that in psql?

> * Add a built-in aggregate for array_agg(anyarray), i.e. build an array
> of dims n+1 from the input arrays of dims n. For n=1 this can be done
> with a simple SQL level aggregate definition, so all it really needs is
> to error on dims > 1 IMO.
> 
> * Add a built-in aggregate form of array_cat
> 
> ... probably other things I'm forgetting.

No idea on these.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +