At 2013-11-15 15:17:32 +0200, hlinnakan...@vmware.com wrote:
>
> I spent some time whacking this around, new patch version attached.
Thanks.
> But I'm not wedded to the idea if someone objects; a log message might
> also be reasonable: "LOG: huge TLB pages are not supported on this
> platform, bu
Hi Martijn,
On Sun, Nov 17, 2013 at 7:56 PM, Martijn van Oosterhout
wrote:
> On Sat, Nov 16, 2013 at 09:26:33PM +0100, Alexey Klyukin wrote:
> > Hi,
> >
> > Attached is the patch that improves usage of '*' wildcard in .pgpass,
> > particularly in the host part. The use case is below.
>
> Looks in
On Sat, Nov 16, 2013 at 4:57 AM, Christopher Browne wrote:
> On Fri, Nov 15, 2013 at 3:14 PM, Peter Eisentraut wrote:
>> On 11/14/13, 4:35 PM, Christopher Browne wrote:> On Thu, Nov 14, 2013 at
>> 5:41 AM, Sameer Thakur wrote:
So i think -g option is failing
>>>
>>> Right you are.
>>>
This
On Thu, Nov 14, 2013 at 6:27 PM, Mika Eloranta wrote:
> On 13 Nov 2013, at 20:51, Mika Eloranta wrote:
>
>> Prevent excessive progress reporting that can grow to gigabytes
>> of output with large databases.
>
> Same patch as an attachment.
>
> --
> Mika Eloranta
> Ohmu Ltd. http://www.ohmu.fi/
>
On 17 November 2013 00:55 Fujii Masao wrote:
> On Sat, Nov 16, 2013 at 2:27 PM, Haribabu kommi
> wrote:
> > on 15 November 2013 17:26 Magnus Hagander wrote:
> >
> >>On Fri, Nov 15, 2013 at 12:10 PM, Haribabu kommi
> >> wrote:
> >
> >>On 14 November 2013 23:59 Fujii Masao wrote:
> >>> On Thu, Nov 1
2013/11/17 Tom Lane
> Pavel Stehule writes:
> > [ rebased patch for RAISE WHEN ]
>
> I have to say I do not see the point of this. It does nothing you
> can't do already with "IF condition THEN RAISE ...". And frankly
> the RAISE statement has got too darn many options already. We don't
> nee
On 2013-11-18 11:39, Amit Kapila wrote:
On Mon, Nov 18, 2013 at 7:32 AM, wrote:
Hi hackers,
I used jdbc to connect to PostgreSQL ,and I found parse
nearly three
times of bind and execute.Is is normaly?
Actually bind and execute should be more than parse. Have yo
On Mon, Nov 18, 2013 at 1:01 AM, Marko Kreen wrote:
> On Thu, Nov 14, 2013 at 09:33:59PM +1300, David Rowley wrote:
> > On Sun, Nov 3, 2013 at 3:18 AM, David Rowley
> wrote:
> > > I'm low on ideas on how to improve things much around here for now, but
> > > for what it's worth, I did create a pa
On Nov 17, 2013, at 8:19 PM, Andrew Dunstan wrote:
> I don't think any name that doesn't begin with "json" is acceptable. I could
> live with "jsonb". It has the merit of brevity, but maybe it's a tad too
> close to "json" to be the right answer.
JSONFTW.
David
--
Sent via pgsql-hackers m
On 11/17/2013 08:49 PM, Josh Berkus wrote:
Now, if it turns out that the new hstore is not dealing with json input
and output, we could have json, jstore and hstore.
Jstore isn't the worst name suggestion I've heard on this thread. The
reason I prefer JSONB though, is that a new user looking f
(2013/11/18 11:25), Claudio Freire wrote:
On Sun, Nov 17, 2013 at 11:02 PM, KONDO Mitsumasa
wrote:
However, my patch is on the way and needed to more improvement. I am
going
to add method of controlling readahead by GUC, for user can freely select
readahed parameter in their transactions.
Ra
On Fri, 2013-11-15 at 00:05 +0530, Atri Sharma wrote:
> Please find the latest version of the patch. This version fixes the
> issues pointed out by the reviewer and the divide by zero bug in
> percent_rank function. This version also adds a regression test for
> the divide by zero case in percent_r
On Mon, Nov 18, 2013 at 7:32 AM, wrote:
> Hi hackers,
>
> I used jdbc to connect to PostgreSQL ,and I found parse nearly
> three
> times of bind and execute.Is is normaly?
Actually bind and execute should be more than parse. Have you
confirmed that by enabling Log/Deb
On Sun, 2013-11-17 at 16:38 -0500, Tom Lane wrote:
> I'm a bit confused as to where this column is coming from? There's
> no such thing in SQL:2008 as far as I can see.
SQL:2011
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Sun, Nov 17, 2013 at 11:02 PM, KONDO Mitsumasa
wrote:
>>> However, my patch is on the way and needed to more improvement. I am
>>> going
>>> to add method of controlling readahead by GUC, for user can freely select
>>> readahed parameter in their transactions.
>>
>>
>> Rather, I'd try to avoid
Hi hackers,
I used jdbc to connect to PostgreSQL ,and I found parse
nearly three
times of bind and execute.Is is normaly? What factors may
cause this result?
The OS is CentOS 5. The PG is 9.0.9. The JDBC is 9.2.
Yours,
Wang Shuo
HighGo Softw
On 18/11/13 14:51, David E. Wheeler wrote:
On Nov 17, 2013, at 5:49 PM, Josh Berkus wrote:
Jstore isn't the worst name suggestion I've heard on this thread. The
reason I prefer JSONB though, is that a new user looking for a place to
put JSON data will clearly realize that JSON and JSONB are a
(2013/11/15 13:48), Claudio Freire wrote:
On Thu, Nov 14, 2013 at 11:13 PM, KONDO Mitsumasa
I use CentOS 6.4 which kernel version is 2.6.32-358.23.2.el6.x86_64 in this
test.
That's close to the kernel version I was using, so you should see the
same effect.
OK. You proposed readahead maximum pa
On Nov 17, 2013, at 5:49 PM, Josh Berkus wrote:
> Jstore isn't the worst name suggestion I've heard on this thread. The
> reason I prefer JSONB though, is that a new user looking for a place to
> put JSON data will clearly realize that JSON and JSONB are alternatives
> and related in some way.
> Now, if it turns out that the new hstore is not dealing with json input
> and output, we could have json, jstore and hstore.
Jstore isn't the worst name suggestion I've heard on this thread. The
reason I prefer JSONB though, is that a new user looking for a place to
put JSON data will clearly
On 11/17/2013 05:44 PM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
That would be one of the silliest and most short-sighted decisions we have
made in many years, IMNSHO. The demand for strong JSON support is enormous.
One of the silliest and most short-sighted decisions we made recently
m
On 18/11/13 09:45, David Johnston wrote:
David E. Wheeler-3 wrote
I like JSONB because:
1. The "B" means "binary"
2. The "B" means "second"
3. It's short
4. See also BYTEA.
"json_strict" :
Not sure about the "bytea" reference off-hand...
I was pondering "jsons" which meets the short property
On 18/11/13 09:02, David E. Wheeler wrote:
On Nov 16, 2013, at 2:04 PM, Hannu Krosing wrote:
It’s still input and output as JSON, though.
Yes, because JavaScript Object Notation *is* a serialization format
(aka Notation) for converting JavaScript Objects to text format
and back :)
I still li
Andrew Dunstan writes:
> That would be one of the silliest and most short-sighted decisions we have
> made in many years, IMNSHO. The demand for strong JSON support is enormous.
One of the silliest and most short-sighted decisions we made recently
might have been to actually ship that json varian
On 11/17/2013 04:51 PM, Dimitri Fontaine wrote:
"David E. Wheeler" writes:
You know that both types support scalar values right? 'a'::JSON works now,
and 'a'::hstore works with the WIP patch. For that reason I would not think
that "doc" or "obj" would be good choices.
I'm wondering about just
On Nov 17, 2013, at 2:26 PM, Dimitri Fontaine wrote:
>> It’s syntax is different than JSON, so one would need to convert to
>> and from JSON all the time to parse and serialize. PITA.
>
> Oh I misremembered about that, I though it would take JSON as input
> as-is and could be made to output JSON
"David E. Wheeler" writes:
> On Nov 17, 2013, at 1:51 PM, Dimitri Fontaine wrote:
>> I'm wondering about just pushing hstore in core (even if technically
>> still an extension, install it by default, like we do for PLpgSQL), and
>> calling it a day.
>
> It’s syntax is different than JSON, so one
On Nov 17, 2013, at 1:51 PM, Dimitri Fontaine wrote:
> I'm wondering about just pushing hstore in core (even if technically
> still an extension, install it by default, like we do for PLpgSQL), and
> calling it a day.
It’s syntax is different than JSON, so one would need to convert to and from
On 11/17/2013 10:51 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> You know that both types support scalar values right? 'a'::JSON works now,
>> and 'a'::hstore works with the WIP patch. For that reason I would not think
>> that "doc" or "obj" would be good choices.
> I'm wondering ab
Pavel Stehule writes:
> [ rebased patch for RAISE WHEN ]
I have to say I do not see the point of this. It does nothing you
can't do already with "IF condition THEN RAISE ...". And frankly
the RAISE statement has got too darn many options already. We don't
need yet more cruft on it that we'll h
On 11/17/2013 09:02 PM, David E. Wheeler wrote:
> On Nov 16, 2013, at 2:04 PM, Hannu Krosing wrote:
>
>>> It’s still input and output as JSON, though.
>> Yes, because JavaScript Object Notation *is* a serialization format
>> (aka Notation) for converting JavaScript Objects to text format
>> and ba
"David E. Wheeler" writes:
> You know that both types support scalar values right? 'a'::JSON works now,
> and 'a'::hstore works with the WIP patch. For that reason I would not think
> that "doc" or "obj" would be good choices.
I'm wondering about just pushing hstore in core (even if technically
s
Peter Eisentraut writes:
> [ 0001-Implement-information_schema.parameters.parameter_de.patch ]
I'm a bit confused as to where this column is coming from? There's
no such thing in SQL:2008 as far as I can see. If it's coming from
some not-yet-ratified draft, maybe we should wait for ratification
David E. Wheeler-3 wrote
> I like JSONB because:
>
> 1. The "B" means "binary"
> 2. The "B" means "second"
> 3. It's short
> 4. See also BYTEA.
"json_strict" :
Not sure about the "bytea" reference off-hand...
I was pondering "jsons" which meets the short property just fine and the
trailing "s"
Alvaro Herrera writes:
> Thanks. I wasn't sure about the error message returned when times are
> outside range; how about this instead? I'm not wedded to this approach
> -- I can return to yours if this one isn't liked -- but I think the
> more specific messages are better. I realize this is in
On Nov 16, 2013, at 4:40 PM, Tom Lane wrote:
>> Co-worker asked a question I could not answer: Why is IF NOT EXISTS not
>> supported by CREATE TABLE AS?
>
> That's an even worse idea than plain CREATE IF NOT EXISTS (which was
> put in over vocal objections from me and some other people). Not o
On Nov 16, 2013, at 2:04 PM, Hannu Krosing wrote:
>> It’s still input and output as JSON, though.
> Yes, because JavaScript Object Notation *is* a serialization format
> (aka Notation) for converting JavaScript Objects to text format
> and back :)
>> I still like JSONB best.
> To me it feels redu
On 11/17/2013 07:31 PM, Andres Freund wrote:
> On 2013-11-17 09:39:26 +0100, Hannu Krosing wrote:
>>> Besides, exactly what would you do in such a trigger?
>> The use case would be telling another system about the rollback.
>>
>> Basically sending a "ignore what I told you to do" message
> But yo
On Sat, Nov 16, 2013 at 09:26:33PM +0100, Alexey Klyukin wrote:
> Hi,
>
> Attached is the patch that improves usage of '*' wildcard in .pgpass,
> particularly in the host part. The use case is below.
Looks interesting, though I wonder if you could use fnmatch(3) here. Or
woud that match more than
On 2013-11-17 09:39:26 +0100, Hannu Krosing wrote:
> > Besides, exactly what would you do in such a trigger?
> The use case would be telling another system about the rollback.
>
> Basically sending a "ignore what I told you to do" message
But you can't rely on it - if e.g. the server restarted/c
Hi All,
I want to modify postgresql code for the first time.
I tried to use netbeans to compile the code.
Now, I wanted to print something on console when I create a table or an
index. I am printing just for testing purpose to get a feel of code.
Please tel me the procedure to run and print usin
Kyotaro HORIGUCHI writes:
> [ union_uses_idx_v2_20131113.patch ]
I'm aware that you said you were going to refactor this, but I took a
quick look through it anyway. I don't think mere refactoring is going
to make me happy with it :-(.
The basic problem here, as well as with some of the hackery
On 11/17/2013 04:20 PM, Alvaro Herrera wrote:
> Hannu Krosing wrote:
>
>> So it would send a network message, a signal or writing something to
>> external file.
> If you're OK with a C function, you could try registering a callback,
> see RegisterXactCallback().
>
I already have an implementation d
Hannu Krosing wrote:
> So it would send a network message, a signal or writing something to
> external file.
If you're OK with a C function, you could try registering a callback,
see RegisterXactCallback().
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x
On Thu, Nov 14, 2013 at 09:33:59PM +1300, David Rowley wrote:
> On Sun, Nov 3, 2013 at 3:18 AM, David Rowley wrote:
> > I'm low on ideas on how to improve things much around here for now, but
> > for what it's worth, I did create a patch which changes unnecessary calls
> > to appendPQExpBuffer() i
Review for Pavel Stehule's patch in CF 2013-11:
https://commitfest.postgresql.org/action/patch_view?id=1253
Patch applies cleanly and works as intended; it's a very straightforward
patch so no surprises there.
The patch expands the range of completable items for \pset, putting
them in alphabet
On 11/17/2013 01:42 AM, Tom Lane wrote:
> Hannu Krosing writes:
>> I have not looked at the patch, but does it also run pre-rollback ?
> error in trigger -> instant infinite loop.
Means this needs to have some kind of recursion depth limit, like python
>>> def x():
... return x()
...
>>> x()
On Fri, Nov 15, 2013 at 11:33 PM, Peter Eisentraut wrote:
> On 11/14/13, 1:02 AM, Sawada Masahiko wrote:
>> I attached patch adds new wal_level 'all'.
>
> Compiler warning:
>
> pg_controldata.c: In function ‘wal_level_str’:
> pg_controldata.c:72:2: warning: enumeration value ‘WAL_LEVEL_ALL’ not ha
48 matches
Mail list logo
