On Tue, Dec 28, 2010 at 16:30, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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 backwar
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 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 t
On Tue, Dec 28, 2010 at 14:39, Robert Haas wrote:
> On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander 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
>>
On Tue, Dec 28, 2010 at 7:49 AM, Magnus Hagander 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 w
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 d
