Hi! On Mon, Nov 27, 2017 at 10:18 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> I though about this design more time. I see following disadvantages > > 1. we are not able to check all possible variants of extended query. If > there will be some custom error, then we will raise pretty ugly error > messages, > Yes, that's an inevitable shortcoming. psql is not backend and can't perform all the required checks on its side... 2. I don't thing so using "Size" as table size in human readable format and > "size" as table size in raw format is intuitive, but any change of "Size" > can introduce some (less probability compatibility issues), > Oh, this is surprisingly hard problem which probably have only imperative solution... 3. What queries will contains size calculations? It is not cheap - requires > AccessShareLock > Sorry, I didn't understand this point. Yes, size calculation requires locking, but that is already true for \dt+ and \l+. Why this is disadvantage of proposed approach? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
