2017-12-08 22:49 GMT+01:00 Alexander Korotkov <a.korot...@postgrespro.ru>:
> 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? > Because you don't know the filter and sort clause (it can be generic), you don't know, if you should to calculate or not the size. Or there should be rule, so filter, order must be limited to displayed columns. Regards Pavel > ------ > Alexander Korotkov > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company >
