Display oprcode and its volatility in \do+

Hi,

Here's a patch for $SUBJECT, displaying information which I find quite
tedious to locate using alternative methods. Hopefully someone else
does, too. Or doesn't. Not sure.

Regards,
Marko Tiikkaja

Hi,

I have reviewed you patch.

-- Patch got applied cleanly (using patch -p1)
-- Make & Make install works fine
-- make check looks good

I done code-walk and it looks good. Also did some manual testing and haven't
found any issue with the implementation.

Even I personally felt the Function and Volatility is nice to have info
into \do+.

Marking it as ready for committer.

Regards,
Rushabh Lathia
www.EnterpriseDB.com

On Fri, Jan 10, 2014 at 7:12 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:

> Hi,
>
> Here's a patch for $SUBJECT, displaying information which I find quite
> tedious to locate using alternative methods. Hopefully someone else does,
> too. Or doesn't. Not sure.
>
>
> Regards,
> Marko Tiikkaja
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>

--
Rushabh Lathia

On 1/16/14 9:53 AM, Rushabh Lathia wrote:
> I have reviewed you patch.
>
> -- Patch got applied cleanly (using patch -p1)
> -- Make & Make install works fine
> -- make check looks good
>
> I done code-walk and it looks good. Also did some manual testing and haven't
> found any issue with the implementation.
>
> Even I personally felt the Function and Volatility is nice to have info
> into \do+.
>
> Marking it as ready for committer.

Thanks for reviewing!

Regards,
Marko Tiikkaja

Marko Tiikkaja <marko(at)joh(dot)to> writes:
> On 1/16/14 9:53 AM, Rushabh Lathia wrote:
>> Even I personally felt the Function and Volatility is nice to have info
>> into \do+.

FWIW, I'm on board with the idea of printing the oprcode, but adding
volatility here seems like probably a waste of valuable terminal width.
I think that the vast majority of operators have immutable or at worst
stable underlying functions, so this doesn't seem like the first bit
of information I'd need about the underlying function. And why print
this but not, say, security, owner, source code, or other columns
shown in \df? ISTM the value of this addition is to give you what
you need to go look in \df, not to try to substitute for that.

regards, tom lane

On 1/16/14 4:22 PM, Tom Lane wrote:
> Marko Tiikkaja <marko(at)joh(dot)to> writes:
>> On 1/16/14 9:53 AM, Rushabh Lathia wrote:
>>> Even I personally felt the Function and Volatility is nice to have info
>>> into \do+.
>
> FWIW, I'm on board with the idea of printing the oprcode, but adding
> volatility here seems like probably a waste of valuable terminal width.
> I think that the vast majority of operators have immutable or at worst
> stable underlying functions, so this doesn't seem like the first bit
> of information I'd need about the underlying function.

Completely unscientifically, 50% of the time I've wanted to know the
oprcode has been because I wanted to know its volatility (exactly
because of the stable oprcodes we have). It seemed like a useful
addition, but I don't feel that strongly about it.

Regards,
Marko Tiikkaja

Marko Tiikkaja <marko(at)joh(dot)to> writes:
> On 1/16/14 4:22 PM, Tom Lane wrote:
>> FWIW, I'm on board with the idea of printing the oprcode, but adding
>> volatility here seems like probably a waste of valuable terminal width.
>> I think that the vast majority of operators have immutable or at worst
>> stable underlying functions, so this doesn't seem like the first bit
>> of information I'd need about the underlying function.

> Completely unscientifically, 50% of the time I've wanted to know the
> oprcode has been because I wanted to know its volatility (exactly
> because of the stable oprcodes we have). It seemed like a useful
> addition, but I don't feel that strongly about it.

Hm. Personally, I've lost count of the number of times I've had to
resort to "select ... from pg_operator" because \do lacked an oprcode
column, but I don't remember that many or indeed any were because
I wanted to check the volatility.

Anybody else have an opinion?

regards, tom lane

I wrote:
> Anybody else have an opinion?

Given the lack of other votes, I pushed this without a volatility column,
and with some other changes --- mostly, I kept the Description column
last, because that's how all the other \d commands do it.

regards, tom lane

On 1/16/14, 9:32 PM, Tom Lane wrote:
> Given the lack of other votes, I pushed this without a volatility column,
> and with some other changes --- mostly, I kept the Description column
> last, because that's how all the other \d commands do it.

Thanks! And looks like I missed the documentation as well, sorry about
that. :-(

Regards,
Marko Tiikkaja

On Thu, Jan 16, 2014 at 5:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> but adding
> volatility here seems like probably a waste of valuable terminal width.
> I think that the vast majority of operators have immutable or at worst
> stable underlying functions, so this doesn't seem like the first bit
> of information I'd need about the underlying function.

For a data point, just today I wanted to look up the volatility of
pg_trgm operators, which made me remember this patch. The \do+ output
is narrow enough, I think an extra volatility column wouldn't be too
bad.

But even just having the function name is a huge improvement, at least
that allows looking up volatility using \commands without accessing
pg_operator directly.

Regards,
Marti