Re: [HACKERS] Function for dealing with xlog data
On Tue, Dec 28, 2010 at 16:30, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Function for dealing with xlog data
On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Function for dealing with xlog data
On Tue, Dec 28, 2010 at 14:39, Robert Haas robertmh...@gmail.com wrote: On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander mag...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Function for dealing with xlog data
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 robertmh...@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 alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Function for dealing with xlog data
Alvaro Herrera alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
