Обсуждение: Function for dealing with xlog data
Currently, a number of functions return data in a really calculation-unfriendly format, e.g: postgres=# select * from pg_current_xlog_location();pg_current_xlog_location --------------------------0/3013158 (1 row) It would be very useful to have a way to convert this to a bigint - so we can do differences between different values easily. And it's AFAIUI easily converted to a 64-bit integer. Would others find this useful as well? What's the best way of doing it? Should we have a function that takes text as input, or should the functions in question be made to return a new datatype that could then be casted? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander <magnus@hagander.net> wrote: > Currently, a number of functions return data in a really > calculation-unfriendly format, e.g: > > postgres=# select * from pg_current_xlog_location(); > pg_current_xlog_location > -------------------------- > 0/3013158 > (1 row) > > It would be very useful to have a way to convert this to a bigint - so > we can do differences between different values easily. And it's AFAIUI > easily converted to a 64-bit integer. > > Would others find this useful as well? Yes. > What's the best way of doing it? Should we have a function that takes > text as input, or should the functions in question be made to return a > new datatype that could then be casted? The new datatype seems more elegant, but a conversion function would be a lot less work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Dec 28, 2010 at 14:39, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander <magnus@hagander.net> wrote: >> Currently, a number of functions return data in a really >> calculation-unfriendly format, e.g: >> >> postgres=# select * from pg_current_xlog_location(); >> pg_current_xlog_location >> -------------------------- >> 0/3013158 >> (1 row) >> >> It would be very useful to have a way to convert this to a bigint - so >> we can do differences between different values easily. And it's AFAIUI >> easily converted to a 64-bit integer. >> >> Would others find this useful as well? > > Yes. > >> What's the best way of doing it? Should we have a function that takes >> text as input, or should the functions in question be made to return a >> new datatype that could then be casted? > > The new datatype seems more elegant, but a conversion function would > be a lot less work. Well, yeah, that was obvious ;) The question is, how much do we prefer the more elegant method? ;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Excerpts from Magnus Hagander's message of mar dic 28 10:46:31 -0300 2010: > On Tue, Dec 28, 2010 at 14:39, Robert Haas <robertmhaas@gmail.com> wrote: > >> What's the best way of doing it? Should we have a function that takes > >> text as input, or should the functions in question be made to return a > >> new datatype that could then be casted? > > > > The new datatype seems more elegant, but a conversion function would > > be a lot less work. > > Well, yeah, that was obvious ;) The question is, how much do we prefer > the more elegant method? ;) If we go the new type route, do we need it to have an implicit cast to text, for backwards compatibility? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Magnus Hagander's message of mar dic 28 10:46:31 -0300 2010:
>> Well, yeah, that was obvious ;) The question is, how much do we prefer
>> the more elegant method? ;)
> If we go the new type route, do we need it to have an implicit cast to
> text, for backwards compatibility?
I'd argue not. Probably all existing uses are just selecting the
function value. What comes back to the client will just be the text
form anyway.
I'm of the opinion that a new type isn't worth the work, myself,
but it would mostly be up to whoever was doing the work.
regards, tom lane
On Tue, Dec 28, 2010 at 16:30, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> Excerpts from Magnus Hagander's message of mar dic 28 10:46:31 -0300 2010: >>> Well, yeah, that was obvious ;) The question is, how much do we prefer >>> the more elegant method? ;) > >> If we go the new type route, do we need it to have an implicit cast to >> text, for backwards compatibility? > > I'd argue not. Probably all existing uses are just selecting the > function value. What comes back to the client will just be the text > form anyway. That's certainly the only thing I've seen. > I'm of the opinion that a new type isn't worth the work, myself, > but it would mostly be up to whoever was doing the work. Fair enough - at least enough people have said it won't be rejected because it's done as a function rather than a datatype - so that seems like the easiest way to proceed. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/