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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
