On Tue, Feb 25, 2014 at 12:41 AM, Robert Haas wrote:
> On Wed, Feb 19, 2014 at 8:27 PM, Michael Paquier
> wrote:
> > On Thu, Feb 20, 2014 at 8:55 AM, Andres Freund
> wrote:
> >> On 2014-02-19 12:47:40 -0500, Robert Haas wrote:
> >>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
> >>> wrote:
On Wed, Feb 19, 2014 at 8:27 PM, Michael Paquier
wrote:
> On Thu, Feb 20, 2014 at 8:55 AM, Andres Freund wrote:
>> On 2014-02-19 12:47:40 -0500, Robert Haas wrote:
>>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
>>> wrote:
>>> >> Yes, that's a good precedent in multiple ways.
>>> > Here are
On Wed, Feb 19, 2014 at 8:06 PM, Michael Paquier
wrote:
> On Thu, Feb 20, 2014 at 9:43 AM, Michael Paquier
> wrote:
>> On Thu, Feb 20, 2014 at 2:47 AM, Robert Haas wrote:
>>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
>>> wrote:
On Thu, Feb 6, 2014 at 3:48 AM, Peter Eisentraut wrote:
On Thu, Feb 20, 2014 at 8:55 AM, Andres Freund wrote:
> On 2014-02-19 12:47:40 -0500, Robert Haas wrote:
>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
>> wrote:
>> >> Yes, that's a good precedent in multiple ways.
>> > Here are updated patches to use pg_lsn instead of pglsn...
>>
>> OK, so I
On Thu, Feb 20, 2014 at 9:43 AM, Michael Paquier
wrote:
> On Thu, Feb 20, 2014 at 2:47 AM, Robert Haas wrote:
>> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
>> wrote:
>>> On Thu, Feb 6, 2014 at 3:48 AM, Peter Eisentraut wrote:
On 2/5/14, 1:31 PM, Robert Haas wrote:
> On Tue, Feb 4,
On Thu, Feb 20, 2014 at 2:47 AM, Robert Haas wrote:
> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
> wrote:
>> On Thu, Feb 6, 2014 at 3:48 AM, Peter Eisentraut wrote:
>>> On 2/5/14, 1:31 PM, Robert Haas wrote:
On Tue, Feb 4, 2014 at 3:26 PM, Peter Eisentraut wrote:
> Perhaps this ty
On 2014-02-19 12:47:40 -0500, Robert Haas wrote:
> On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
> wrote:
> >> Yes, that's a good precedent in multiple ways.
> > Here are updated patches to use pg_lsn instead of pglsn...
>
> OK, so I think this stuff is all committed now, with assorted changes.
On Wed, Feb 5, 2014 at 9:26 PM, Michael Paquier
wrote:
> On Thu, Feb 6, 2014 at 3:48 AM, Peter Eisentraut wrote:
>> On 2/5/14, 1:31 PM, Robert Haas wrote:
>>> On Tue, Feb 4, 2014 at 3:26 PM, Peter Eisentraut wrote:
Perhaps this type should be called pglsn, since it's an
implementation-
On Wed, Feb 19, 2014 at 11:03 AM, Greg Stark wrote:
> On Wed, Feb 19, 2014 at 3:11 PM, Robert Haas wrote:
>> Hopefully the commit I just pushed will fix it. It now works on my
>> machine with and without --disable-float8-byval.
>
> It builds and passes here on 32bits
The buildfarm seems happy s
On Wed, Feb 19, 2014 at 3:11 PM, Robert Haas wrote:
> Hopefully the commit I just pushed will fix it. It now works on my
> machine with and without --disable-float8-byval.
It builds and passes here on 32bits
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Wed, Feb 19, 2014 at 10:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 19, 2014 at 9:30 AM, Andres Freund
>> wrote:
>>> GET_8_BYTES only exists for 64bit systems.
>
>> Right, I got that far. So it looks like float8, int8, timestamp,
>> timestamptz, and money all have behavior c
Robert Haas writes:
> On Wed, Feb 19, 2014 at 9:30 AM, Andres Freund wrote:
>> GET_8_BYTES only exists for 64bit systems.
> Right, I got that far. So it looks like float8, int8, timestamp,
> timestamptz, and money all have behavior contingent on
> USE_FLOAT8_BYVAL, making that symbol a misnomer
On Wed, Feb 19, 2014 at 9:30 AM, Andres Freund wrote:
> On 2014-02-19 09:24:03 -0500, Robert Haas wrote:
>> On Fri, Feb 14, 2014 at 9:32 PM, Michael Paquier
>> wrote:
>> > On Thu, Feb 6, 2014 at 11:26 AM, Michael Paquier
>> > wrote:
>> >> Here are updated patches to use pg_lsn instead of pglsn..
On 2014-02-19 09:24:03 -0500, Robert Haas wrote:
> On Fri, Feb 14, 2014 at 9:32 PM, Michael Paquier
> wrote:
> > On Thu, Feb 6, 2014 at 11:26 AM, Michael Paquier
> > wrote:
> >> Here are updated patches to use pg_lsn instead of pglsn...
> > Should I register this patch somewhere to avoid having i
On Fri, Feb 14, 2014 at 9:32 PM, Michael Paquier
wrote:
> On Thu, Feb 6, 2014 at 11:26 AM, Michael Paquier
> wrote:
>> Here are updated patches to use pg_lsn instead of pglsn...
> Should I register this patch somewhere to avoid having it lost in the void?
> Regards,
Well, I committed this, but t
On Thu, Feb 6, 2014 at 11:26 AM, Michael Paquier
wrote:
> Here are updated patches to use pg_lsn instead of pglsn...
Should I register this patch somewhere to avoid having it lost in the void?
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On 2/5/14, 1:31 PM, Robert Haas wrote:
> On Tue, Feb 4, 2014 at 3:26 PM, Peter Eisentraut wrote:
>> Perhaps this type should be called pglsn, since it's an
>> implementation-specific detail and not a universal concept like int,
>> point, or uuid.
>
> If we're going to do that, I suggest pg_lsn ra
On Tue, Feb 4, 2014 at 3:26 PM, Peter Eisentraut wrote:
> Perhaps this type should be called pglsn, since it's an
> implementation-specific detail and not a universal concept like int,
> point, or uuid.
If we're going to do that, I suggest pg_lsn rather than pglsn. We
already have pg_node_tree,
On Wed, Feb 5, 2014 at 9:38 AM, Michael Paquier
wrote:
> On Wed, Feb 5, 2014 at 8:59 AM, Michael Paquier
> wrote:
>> I'll update the patches according to that.
> Here are the updated patches with the following changes (according to
> previous comments):
> - Datatype is renamed to pglsn, document
On Wed, Feb 5, 2014 at 5:26 AM, Peter Eisentraut wrote:
> Perhaps this type should be called pglsn, since it's an
> implementation-specific detail and not a universal concept like int,
> point, or uuid.
It makes sense. I'll update the patches according to that.
--
Michael
--
Sent via pgsql-hac
Perhaps this type should be called pglsn, since it's an
implementation-specific detail and not a universal concept like int,
point, or uuid.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
On 2014-02-04 21:04:13 +0900, Michael Paquier wrote:
> On Tue, Feb 4, 2014 at 7:22 PM, Andres Freund wrote:
> > On 2014-02-04 19:17:51 +0900, Michael Paquier wrote:
> >> @@ -180,7 +175,7 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)
> >> else
> >> nulls[i++]
On Tue, Feb 4, 2014 at 7:22 PM, Andres Freund wrote:
> On 2014-02-04 19:17:51 +0900, Michael Paquier wrote:
>> @@ -180,7 +175,7 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)
>> else
>> nulls[i++] = true;
>> if (restart_lsn != InvalidTransacti
On 2014-02-04 19:17:51 +0900, Michael Paquier wrote:
> On Tue, Feb 4, 2014 at 6:15 PM, Andres Freund wrote:
> >
> >> + /*--
> >> + * Relational operators for LSNs
> >> + *-*/
> >
> >
On Tue, Feb 4, 2014 at 6:15 PM, Andres Freund wrote:
>
>> + /*--
>> + * Relational operators for LSNs
>> + *-*/
>
> Isn't it just operators? They aren't really relational...
Operators
Hi,
On 2014-02-04 10:23:14 +0900, Michael Paquier wrote:
> On Tue, Feb 4, 2014 at 10:10 AM, Tom Lane wrote:
> > Michael Paquier writes:
> >> Please find attached a patch implementing lsn as a datatype, based on
> >> the one Robert wrote a couple of years ago.
> >
> >> Patch contains regression t
On Tue, Feb 4, 2014 at 10:10 AM, Tom Lane wrote:
> Michael Paquier writes:
>> Please find attached a patch implementing lsn as a datatype, based on
>> the one Robert wrote a couple of years ago.
>
>> Patch contains regression tests as well as a bit of documentation.
>> Perhaps this is too late fo
Michael Paquier writes:
> Please find attached a patch implementing lsn as a datatype, based on
> the one Robert wrote a couple of years ago.
> Patch contains regression tests as well as a bit of documentation.
> Perhaps this is too late for 9.4, so if there are no objections I'll
> simply add th
On Sun, Feb 2, 2014 at 12:07 AM, Andres Freund wrote:
> On 2014-02-02 00:04:41 +0900, Michael Paquier wrote:
>> On Fri, Dec 13, 2013 at 2:47 AM, Tom Lane wrote:
>> > Andres Freund writes:
>> >> On 2013-12-12 11:55:51 -0500, Tom Lane wrote:
>> >>> I'm not, however, terribly thrilled with the sugg
On 2014-02-02 00:04:41 +0900, Michael Paquier wrote:
> On Fri, Dec 13, 2013 at 2:47 AM, Tom Lane wrote:
> > Andres Freund writes:
> >> On 2013-12-12 11:55:51 -0500, Tom Lane wrote:
> >>> I'm not, however, terribly thrilled with the suggestions to add implicit
> >>> casts associated with this type
On Fri, Dec 13, 2013 at 2:47 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-12-12 11:55:51 -0500, Tom Lane wrote:
>>> I'm not, however, terribly thrilled with the suggestions to add implicit
>>> casts associated with this type. Implicit casts are generally dangerous.
>
>> It's a tradeof.
Andres Freund writes:
> On 2013-12-12 11:55:51 -0500, Tom Lane wrote:
>> I'm not, however, terribly thrilled with the suggestions to add implicit
>> casts associated with this type. Implicit casts are generally dangerous.
> It's a tradeof. Currently we have the following functions returning LSNs
Hi,
On 2013-12-12 11:55:51 -0500, Tom Lane wrote:
> I'm not, however, terribly thrilled with the suggestions to add implicit
> casts associated with this type. Implicit casts are generally dangerous.
It's a tradeof. Currently we have the following functions returning LSNs
as text:
* pg_current_x
Alvaro Herrera writes:
> Robert Haas escribió:
>> I am happy to have my old patch resurrected - could become a trend.
>> But someone should probably go back and check who objected and for
>> what reasons.
> Here it is FWIW:
> http://www.postgresql.org/message-id/flat/ca+tgmozrmnn0evesd-kxb9e-mvdm
Robert Haas escribió:
> I am happy to have my old patch resurrected - could become a trend.
> But someone should probably go back and check who objected and for
> what reasons.
Here it is FWIW:
http://www.postgresql.org/message-id/flat/ca+tgmozrmnn0evesd-kxb9e-mvdmwoti6guujuvqp_8q2c5...@mail.gma
On Thu, Dec 12, 2013 at 8:20 AM, Simon Riggs wrote:
> On 12 December 2013 12:27, Andres Freund wrote:
>> On 2013-12-11 08:13:18 -0500, Robert Haas wrote:
>>> On Wed, Dec 11, 2013 at 7:41 AM, Andres Freund
>>> wrote:
>>> > There's already a couple of SQL function dealing with XLogRecPtrs and
>>>
On 12 December 2013 12:27, Andres Freund wrote:
> On 2013-12-11 08:13:18 -0500, Robert Haas wrote:
>> On Wed, Dec 11, 2013 at 7:41 AM, Andres Freund
>> wrote:
>> > There's already a couple of SQL function dealing with XLogRecPtrs and
>> > the logical replication work will add a couple of more. C
On 2013-12-11 08:13:18 -0500, Robert Haas wrote:
> On Wed, Dec 11, 2013 at 7:41 AM, Andres Freund wrote:
> > There's already a couple of SQL function dealing with XLogRecPtrs and
> > the logical replication work will add a couple of more. Currently each
> > of those funtions taking/returning an LS
Bonus points if you implement a (explicit) cast to and from timestamptz :)
--
greg
On 11 Dec 2013 12:41, "Andres Freund" wrote:
> Hi,
>
> There's already a couple of SQL function dealing with XLogRecPtrs and
> the logical replication work will add a couple of more. Currently each
> of those fun
On 11-12-2013 09:41, Andres Freund wrote:
> There's already a couple of SQL function dealing with XLogRecPtrs and
> the logical replication work will add a couple of more. Currently each
> of those funtions taking/returning an LSN does sprintf/scanf to
> print/parse the strings. Which both is awkwa
On Wed, Dec 11, 2013 at 7:41 AM, Andres Freund wrote:
> There's already a couple of SQL function dealing with XLogRecPtrs and
> the logical replication work will add a couple of more. Currently each
> of those funtions taking/returning an LSN does sprintf/scanf to
> print/parse the strings. Which
Hi,
There's already a couple of SQL function dealing with XLogRecPtrs and
the logical replication work will add a couple of more. Currently each
of those funtions taking/returning an LSN does sprintf/scanf to
print/parse the strings. Which both is awkward and potentially
noticeable performancewise
42 matches
Mail list logo
