From: | Ian Lawrence Barwick <barwick(at)gmail(dot)com> |
---|---|
To: | Eric Radman <ericshane(at)eradman(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] Add function to_oct |
Date: | 2022-12-21 01:56:29 |
Message-ID: | CAB8KJ=g4kbRPAPLq9jwKQbzqG8tX4gFAc2rFgz-SKjUzJ7PsFQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2022年12月21日(水) 10:42 Eric Radman <ericshane(at)eradman(dot)com>:
>
> On Wed, Dec 21, 2022 at 08:36:40AM +0900, Ian Lawrence Barwick wrote:
> > 2022年12月21日(水) 7:08 Eric Radman <ericshane(at)eradman(dot)com>:>
> > > Hello!
> > >
> > > This patch is a new function based on the implementation of to_hex(int).
> > >
> > > Since support for octal integer literals was added, to_oct(int) allows
> > > octal values to be easily stored and returned in query results.
> > >
> > > to_oct(0o755) = '755'
> > >
> > > This is probably most useful for storing file system permissions.
> >
> > Seems like it would be convenient to have. Any reason why there's
> > no matching "to_oct(bigint)" version?
>
> I couldn't think of a reason someone might want an octal
> representation of a bigint. Certainly it would be easy to add
> if there is value in supporting all of the same argument types.
Yeah, I am struggling to think of a practical application other than
symmetry with to_hex().
Regards
Ian Barwick
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2022-12-21 02:01:41 | Re: Perform streaming logical transactions by background workers and parallel apply |
Previous Message | Jonathan S. Katz | 2022-12-21 01:45:29 | Re: Refactor SCRAM code to dynamically handle hash type and key length |