On 09/02/2014 00:06, Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool now. Isn't it be
2014-02-09 4:16 GMT+01:00 Peter Eisentraut :
> I posted an updated patch in the original thread. Please see the commit
> fest web site for the URL.
>
>
> On Thu, 2014-01-30 at 19:50 +0100, Pavel Stehule wrote:
>
> > 6. I found only few issues:
> >
> >
> > a) Configure doesn't check a required IRC
I posted an updated patch in the original thread. Please see the commit
fest web site for the URL.
On Thu, 2014-01-30 at 19:50 +0100, Pavel Stehule wrote:
> 6. I found only few issues:
>
>
> a) Configure doesn't check a required IRC::Run module
Clearly, we will need to figure out something a
On Wed, 2014-01-15 at 20:56 +0100, Erik Rijkers wrote:
> 2 tests stumbled:
>
> 1. One test ( pg_ctl/t/001_start_stop.pl ) failed because I had PGDATA set.
> I unset all PG+ vars after that. No a big
> problem but nonetheless it might be better if the test suite removes
> /controls the variab
On Fri, 2013-12-20 at 00:09 +0100, Andres Freund wrote:
> The attached patch fixes some of the easiest cases, where either an
> include was missing o a variable should have been static.
committed
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
On 1/27/14, 12:04 PM, Simon Riggs wrote:
Florian's point was well made and we must come up with something that
allows warning/errors at compile time and once accepted, nothing at
run time.
I've been thinking about this, and I'm not sure I like this idea all
that much. For compile-time warning
On 9 February 2014 01:06, Andres Freund wrote:
> On 2014-02-09 00:49:31 +, Thom Brown wrote:
>> # ALTER TABLE test ADD COLUMN a decimal DEFAULT 2.22;
>> ALTER TABLE
>>
>> # ALTER TABLE test ADD COLUMN b json DEFAULT '{"a":[1,2,3],"b":[4,5,6]}';
>> ALTER TABLE
>>
>> The output generated by thos
On 2014-02-09 00:49:31 +, Thom Brown wrote:
> # ALTER TABLE test ADD COLUMN a decimal DEFAULT 2.22;
> ALTER TABLE
>
> # ALTER TABLE test ADD COLUMN b json DEFAULT '{"a":[1,2,3],"b":[4,5,6]}';
> ALTER TABLE
>
> The output generated by those last 2 statements is:
>
> BEGIN 891
> table "pg_temp
On 8 February 2014 23:08, Andres Freund wrote:
> On 2014-02-08 22:58:35 +, Thom Brown wrote:
>> Another question: in order for logical decoding/replication to be
>> useful, presumably one would need a primary key on every table? It's
>> just I haven't seen this mentioned on the changeset extr
Andres Freund writes:
> I think that there's a small problem with your patch, namely that you
> made the explicit PGDLLEXPORT definition empty, but that's currently
> used in fmgr.h for the function and module magic, I think we actually
> need those to be __declspec(dllexport)ed when building an e
On 2014-02-08 22:58:35 +, Thom Brown wrote:
> Another question: in order for logical decoding/replication to be
> useful, presumably one would need a primary key on every table? It's
> just I haven't seen this mentioned on the changeset extraction page in
> the docs.
Hm, that's a good point.
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool now. Isn't it better for MINGW port to
follow it?
Only way to
On 2014-02-08 17:34:32 -0500, Tom Lane wrote:
> Hiroshi Inoue writes:
> > Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
> > tool and dlltool is almost a deprecated tool. Cygwin port is removing
> > the use of dllwrap and dlltool now. Isn't it better for MINGW port to
> > fol
On 8 February 2014 22:47, Andres Freund wrote:
> Hi Thom,
>
> On 2014-02-08 22:26:59 +, Thom Brown wrote:
>> Got a question about ranges and arrays usage with timestamps... why
>> are quotes added to these?
>>
>> timestamptz (no quotes with input or output):
>> table "a": INSERT: moo[timestamp
Hi Thom,
On 2014-02-08 22:26:59 +, Thom Brown wrote:
> Got a question about ranges and arrays usage with timestamps... why
> are quotes added to these?
>
> timestamptz (no quotes with input or output):
> table "a": INSERT: moo[timestamptz]:2014-02-08 22:09:33+00
>
> tstzrange (no quotes with
Hiroshi Inoue writes:
> Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
> tool and dlltool is almost a deprecated tool. Cygwin port is removing
> the use of dllwrap and dlltool now. Isn't it better for MINGW port to
> follow it?
Only way to make that happen is to prepare and
On 8 February 2014 21:25, Andres Freund wrote:
> On 2014-02-08 21:07:03 +, Thom Brown wrote:
>> > I'll continue to play around with the feature.
>>
>> Next issue. Firstly, an out-of-date example:
>>
>> doc/src/sgml/changesetextraction.sgml
>>
>> pg_recvlogical --slot test --init -d testdb
>>
I wrote:
> Gavin Flower writes:
>> How about adding URL's for the online versions of HISTORY & README's (or
>> their rough equivalents - perhaps the online version of the latest
>> 'Appendix E. Release Notes' would be sufficient?) to the INSTALL file?
> Actually, what I had in mind was to repla
On 2014-02-08 21:07:03 +, Thom Brown wrote:
> > I'll continue to play around with the feature.
>
> Next issue. Firstly, an out-of-date example:
>
> doc/src/sgml/changesetextraction.sgml
>
> pg_recvlogical --slot test --init -d testdb
>
> There's no option --init. I think this is supposed
On 8 February 2014 19:35, Thom Brown wrote:
> On 8 February 2014 17:52, Andres Freund wrote:
>> Hi,
>>
>> Only got to this now, was a bit too tired and needed to catch up on some
>> real-world stuff...
>>
>> On 2014-02-08 00:16:07 +, Thom Brown wrote:
>>> On 7 February 2014 23:43, Andres Freu
Tom Lane schrieb:
> Hardy Falk writes:
>>> Well, you didn't add any code, so it's hard to say... Simple ways of
>>> doing what I think you describe will remove the queue's order. Do you
>>> preserve the ordering guarantees?
>
>> Yes, the order is preserved.
>> I didn't remove the the original lis
On 8 February 2014 17:52, Andres Freund wrote:
> Hi,
>
> Only got to this now, was a bit too tired and needed to catch up on some
> real-world stuff...
>
> On 2014-02-08 00:16:07 +, Thom Brown wrote:
>> On 7 February 2014 23:43, Andres Freund wrote:
>> > Thanks, that's a bug indeed. I have ex
Hardy Falk writes:
>> Well, you didn't add any code, so it's hard to say... Simple ways of
>> doing what I think you describe will remove the queue's order. Do you
>> preserve the ordering guarantees?
> Yes, the order is preserved.
> I didn't remove the the original list code.
> The tree is just
Hi,
On 2014-02-08 19:28:56 +0100, Hardy Falk wrote:
> > Well, you didn't add any code, so it's hard to say... Simple ways of
> > doing what I think you describe will remove the queue's order. Do you
> > preserve the ordering guarantees?
> >
> > Greetings,
> >
> > Andres Freund
> >
> Yes, the or
> Well, you didn't add any code, so it's hard to say... Simple ways of
> doing what I think you describe will remove the queue's order. Do you
> preserve the ordering guarantees?
>
> Greetings,
>
> Andres Freund
>
Yes, the order is preserved.
I didn't remove the the original list code.
The tree
Hi,
On 2014-02-08 18:56:41 +0100, Hardy Falk wrote:
> I know that it is not a big problem for most users, but allowing a very
> large number of notifications while using linear search is a bit dumb.
> I can fix this with a very small modification to
> struct Notification:
> {
> char *channel
I know that it is not a big problem for most users, but allowing a very
large number of notifications while using linear search is a bit dumb.
I can fix this with a very small modification to
struct Notification:
{
char *channel ;
char *payload ;
uint32 hash ;
struct
Hi,
Only got to this now, was a bit too tired and needed to catch up on some
real-world stuff...
On 2014-02-08 00:16:07 +, Thom Brown wrote:
> On 7 February 2014 23:43, Andres Freund wrote:
> > Thanks, that's a bug indeed. I have experimentally fixed the bug, not
> > sure whether I like the
Now that the dust seems to have settled around 9.3's multixact bugs,
it's time to push out another set of minor releases. The plan is to
wrap tarballs on Monday Feb 17 for announcement on Thursday Feb 20.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-h
29 matches
Mail list logo
