On Wed, Nov 13, 2013 at 2:42 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/13/2013 06:36 AM, Rohit Goyal wrote:
Hi,
Thanks for document. It was really helpful.
Now, as index folder contains basically interface for all index type, do
I need to change it, if I want to modify only b
On Wed, Nov 13, 2013 at 1:22 PM, Luca Ferrari fluca1...@infinito.it wrote:
I'm wondering what is the problem in placing the old/original name
after the pg.dropped prefix. I know that the tuple in pg_attribute
is temporary, but what are the possible conflicts the comment talks
about?
May
Hi,
On 2013-11-13 08:52:27 +0100, Luca Ferrari wrote:
when you drop a column on a table the pg_attribute is updated and the
name of the column is changed with an almost fixed identifier that
reports only the original column position:
/*
* Change the column name to something that isn't
2013/11/12 Claudio Freire klaussfre...@gmail.com:
On Tue, Nov 12, 2013 at 6:41 PM, Nicolas Barbier
nicolas.barb...@gmail.com wrote:
(Note that K B-trees can be merged by simply scanning all of them
concurrently, and merging them just like a merge sort merges runs.
Also, all B-trees except
On 11/13/2013 08:59 AM, Rohit Goyal wrote:
Could you please suggest something about abt update operation of B tree
index.
access/nbtree/README is probably the next text to read. It points to
theoretical background and also explains specifics of Postgres
implementation.
// Antonin Houska (Tony)
Thank you for pointing out. I missed the warning.
There is a new compiler warning:
setrefs.c: In function ‘set_plan_refs’:
setrefs.c:782:7: warning: initialization from incompatible pointer type
[enabled by default]
Added explicit cast there and rebased to current master.
Checked no new
Umm. I might be working on a bit unstable place..
Your patch doesn't apply anymore. Please rebase it.
Thank you. I rebased all patches to current master.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/optimizer/path/equivclass.c
Tomas Vondra wrote:
have you found a way to pass data types other than TID as a resjunk
column? I'm trying to solve almost the same thing (pass INT8 instead of
TID), but I got stuck.
Adding a custom Var with INT8OID instead of TIDOID seems to work fine,
but I've found no way to populate
On 12 November 2013 19:54, Claudio Freire klaussfre...@gmail.com wrote:
On Tue, Nov 12, 2013 at 7:14 PM, Simon Riggs si...@2ndquadrant.com wrote:
I still think we need to look at this from a query perspective though.
We need to check whether there is a class of real world queries that
are not
2013/11/12 Simon Riggs si...@2ndquadrant.com:
On 12 November 2013 21:41, Nicolas Barbier nicolas.barb...@gmail.com wrote:
Look-up speed is as follows: Each look-up must look through all
B-trees.
That can be optimised by using a min max approach, so we need only
look at sub-trees that may
Simon Riggs wrote
On 5 November 2013 14:28, Leonardo Francalanci lt;
m_lists@
gt; wrote:
Either my sql is not correct (likely), or my understanding of the minmax
index is
not correct (even more likely), or the minmax index is not usable in a
random inputs
scenario.
Please show the
David et al,
How about something like this?
Cheers,
Colin
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index e603b76..a68014b 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -33,13 +33,14 @@ PostgreSQL documentation
refsynopsisdiv
Hi,
While looking at the documentation on SELECT I noticed that the
entries in reference.sgml aren't sorted correctly -- psql \h does have
them in the correct order.
Attached a trivial patch to fix this.
In addition, reference.sgml doesn't have entries for TABLE or WITH
which should link to
Here http://www.postgresql.org/message-id/24278.1352922...@sss.pgh.pa.us there
was some talk about init_sequence being a bottleneck when many sequences
are used in a single backend.
The attached I think implements what was talked about in the above link
which for me seems to double the speed of a
On 01 October 2013 00:56 Amit Kapila wrote:
On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 9/28/13 3:05 AM, Amit Kapila wrote:
Now as we have an agreement, I had updated patch for below left
issues:
Regression tests are failing.
Thanks for informing. I
On 13 November 2013 06:07, Leonardo Francalanci m_li...@yahoo.it wrote:
The use case is pretty simple.
Think it as the NSA, as it would be much easier.
Collect all calls made/received by any user on a mobile network.
(in fact, it's something more than calls, so in fact is 2-10 rows per call).
On 13.11.2013 11:55, David Rowley wrote:
I thought I would post the patch early to see if this is actually wanted
before I do too much more work on it.
Seems reasonable.
My implementation maintains using the linear list for sequences up to a
defined threshold (currently 32) then it moves
On Wed, Nov 13, 2013 at 9:00 AM, Andres Freund and...@2ndquadrant.com wrote:
The old name might not fit there, attribute names have a relatively low
maximum length (64 by default), so we cannot always fit the entire old
name there.
Thanks, I was guessing this.
Also, think about:
CREATE
Hi all,
The function of custom script of pgbench allows only BUFSIZ
(i.g.,1024byte) or less as length of a SQL.
I think that when we want to bench mark with long SQL then it will difficult.
At that time even pgbench doesn't return ERROR. It will try to do
query with the broken SQL.
And user can
On 13/11/13 09:07, Leonardo Francalanci wrote:
Problem? having 4 btree indexes on random values (imsi+imei * 2,
since we have calling and caller) kills the performance in insertion
after a while.
Surely there's good correlation between IMSI IMEI, so have a separate
table to translate one to
On Thu, 2013-11-07 at 19:13 +1300, David Rowley wrote:
Attached is a small patch which fixes the unused variable warning in
the visual studios build. Seems like VS does not
support __attribute__((unused)) but looks like all other places we
must assign to the variable.
committed
--
Sent
When an external recovery command such as restore_command or
archive_cleanup_command fails, it just reports return code 34567 or
something, but we have facilities to do decode this properly, so use
them.
From 8aa3cf503fe1c1f41a2a833c008f4273c22a86c9 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
On 1 August 2013 01:53, Noah Misch n...@leadboat.com wrote:
A remediation strategy that seemed attractive when I last contemplated this
problem is to repoint rd_att immediately but arrange to free the obsolete
TupleDesc in AtEOXact_RelationCache().
I agree that the best way to resolve this is
On 12.11.2013 21:33, Teodor Sigaev wrote:
Suppose, some last changes in GIN are broken, 9.3 works fine.
Fixed, thanks for the report.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Simon Riggs wrote
So in the use case you describe, the min max index would require a
scan of only 25% of the table, not the 80% described earlier for
random inserts. In my experience, people wish to keep data for much
longer periods and so the percentage of scan required would drop lower
than
Jeremy Harris wrote
Surely there's good correlation between IMSI IMEI, so have a separate
table to translate one to (a group of) the others, and
halve the indexes on your main table?
Yes; unfortunately not always both are available; but it's something
we are thinking about (it requires logic
On 11/11/2013 02:06 PM, Andres Freund wrote:
On 2013-11-10 14:45:17 -0500, Steve Singer wrote:
Not really keen - that'd be a noticeable overhead. Note that in the
cases where DEFAULT|INDEX is used, you can just use the new tuple to
extract what you need for the pkey lookup since they now have
On 11/13/13, 6:18 AM, Sawada Masahiko wrote:
Hi all,
The function of custom script of pgbench allows only BUFSIZ
(i.g.,1024byte) or less as length of a SQL.
I think that when we want to bench mark with long SQL then it will difficult.
At that time even pgbench doesn't return ERROR. It
Peter Eisentraut pete...@gmx.net writes:
On 11/13/13, 6:18 AM, Sawada Masahiko wrote:
The function of custom script of pgbench allows only BUFSIZ
(i.g.,1024byte) or less as length of a SQL.
So I'm thinking following solution.
(1) to increase buffer size
(2) to change to variable buffer size
On 13 November 2013 09:31, Leonardo Francalanci m_li...@yahoo.it wrote:
Or, in other words: what are you going to write in the minmax index
documentation, try and see if they work better for you?
That seems like good advice to me. Bacon Aristotle.
There is very little written about
On 11/12/13, 10:48 PM, Andrew Dunstan wrote:
You quoted me out of context. Your prevuious para referred to
duplicate_oids.
... which was in turn quoted out of context. ;-)
What exactly is your argument, here?
If we change unused_oids to a Perl implementation, we will add
additional
The commit fest manager mace has been passed on to me[*]. More to follow.
[*] Actually, I found it behind the dumpster in the alley.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Nov 13, 2013 at 8:45 AM, Peter Eisentraut pete...@gmx.net wrote:
The commit fest manager mace has been passed on to me[*]. More to follow.
[*] Actually, I found it behind the dumpster in the alley.
ROFL.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On Wed, Nov 13, 2013 at 4:05 PM, Haribabu kommi
haribabu.ko...@huawei.com wrote:
On 01 October 2013 00:56 Amit Kapila wrote:
On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut pete...@gmx.net
wrote:
On 9/28/13 3:05 AM, Amit Kapila wrote:
Now as we have an agreement, I had updated patch for
On 11/13/2013 08:36 AM, Peter Eisentraut wrote:
What exactly is your argument, here?
If we change unused_oids to a Perl implementation, we will add
additional inconvenience to users who don't have /usr/bin/perl in that
exact location. Versus allowing use by users who don't have /bin/sh. I
On 11/12/13, 1:57 AM, Tatsuo Ishii wrote:
Currently there's no such an universal encoding in the universe, I
think the only way is, inventing it by ourselves.
I think ISO 2022 is something in that direction, but it's not
ASCII-safe, AFAICT.
--
Sent via pgsql-hackers mailing list
On Wed, Nov 13, 2013 at 10:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On 11/13/13, 6:18 AM, Sawada Masahiko wrote:
The function of custom script of pgbench allows only BUFSIZ
(i.g.,1024byte) or less as length of a SQL.
So I'm thinking following
Simon Riggs wrote
From our discussions here, IMHO there is a strong case for avoiding
btrees completely for larger historical data tables. That isn't
something I had even considered as desirable before this conversation
but ISTM now that taking that approach will be more fruitful than
On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/13/2013 02:34 AM, Andrew Dunstan wrote:
If there's agreement on taking these, I will prepare patches and submit
them by the 15th.
With JSON enhancement, my only concern is that there's work ongoing to
integrate
On Wed, Nov 13, 2013 at 7:33 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 13 November 2013 09:31, Leonardo Francalanci m_li...@yahoo.it wrote:
I would like to see some numbers.
Alvaro has given me some results for his patch. The figures I have are
for a 2GB table.
Index Build Time
On 13 November 2013 11:54, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Nov 13, 2013 at 7:33 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 13 November 2013 09:31, Leonardo Francalanci m_li...@yahoo.it wrote:
I would like to see some numbers.
Alvaro has given me some results for his
On 13 November 2013 11:54, Merlin Moncure mmonc...@gmail.com wrote:
Load time
MinMax no overhead, same as raw COPY
BTree - considerably slower
And just as a general comment, the min max index does not slow down
COPY as the table gets larger, whereas the btree gets slower as the
table gets
On Tue, Nov 12, 2013 at 08:39:35PM -0500, Bruce Momjian wrote:
My specific wording is incoherent mostly because it really belongs to a
larger corpus that currently exists only in my head.
Oh, OK, it sounds fine. The user really doesn't choose what timeline to
see --- rather, it is the
On Wed, Nov 13, 2013 at 08:58:07AM +0530, Amit Kapila wrote:
On Tue, Nov 12, 2013 at 9:37 PM, Bruce Momjian br...@momjian.us wrote:
On Wed, Oct 23, 2013 at 10:31:39AM +0530, Amit Kapila wrote:
On Tue, Oct 22, 2013 at 3:04 AM, Piotr Marcinczyk pmarc...@gmail.com
wrote:
Hi,
I would
When pg_upgrade encounters a full disk while copying relation files,
it reports this as:
error while copying relation xyz (...): Success
because it doesn't set errno in some error cases. In other places we
treat short writes as ENOSPC, so here is a patch to do that for
pg_upgrade as well.
diff
Simon Riggs wrote
Can you CLUSTER
against a minmax index?
Not in this release, at least in my understanding. It's not yet
possible to do an ordered fetch, so the cluster scan probably won't
work.
As per the patch I helped writing, CLUSTER should use the
sequential heap scan+sort when it
On 11/13/2013 09:45 AM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/13/2013 02:34 AM, Andrew Dunstan wrote:
If there's agreement on taking these, I will prepare patches and submit
them by the 15th.
With JSON enhancement, my only
Tom Lane t...@sss.pgh.pa.us wrote:
No, this isn't about test code vs production, it's about not bothering
to free memory explicitly when a program is about to terminate. Alvaro
is suggesting that the proposed addition to pg_regress.c is just a waste
of cycles. IMO it's not that big a deal
On Mon, Nov 11, 2013 at 4:34 PM, Andres Freund and...@2ndquadrant.com wrote:
I'm pretty sure that the current coding, which blows away the whole
relation, is used in other places, and I really don't see why it
should be fundamentally flawed, or why we should change it to clear
the cache entries
On Tue, Nov 12, 2013 at 09:55:34AM -0500, Robert Haas wrote:
On Fri, Nov 8, 2013 at 4:13 PM, Noah Misch n...@leadboat.com wrote:
A PANIC will reinitialize everything relevant, largely resolving the
problems
around ERROR during FATAL. It's a heavy-handed solution, but it may well be
the
On 2013-11-12 19:24:39 +0100, Andres Freund wrote:
On 2013-11-12 13:18:19 -0500, Robert Haas wrote:
On Tue, Nov 12, 2013 at 12:50 PM, Andres Freund and...@2ndquadrant.com
wrote:
Completely agreed. As evidenced by the fact that the current change
doesn't update all relevant comments
On Mon, Nov 11, 2013 at 11:10 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 11/11/2013 06:37 PM, Kohei KaiGai wrote:
I'd like to vote the last options. It is a separate problem (or, might
be specification), I think.
I tend to agree, but I'm nervous about entirely hand-waving around this,
On Wed, Nov 13, 2013 at 9:32 AM, Andrew Dunstan and...@dunslane.net wrote:
I'm not so sure we should require hstore to do things like build
arbitrary json objects even though I agree that hstore will probably
displace json for must cases where you want to store nested data (as
opposed to
Looks like we got another set of errors overnight. Here's the log file
from the errors. (Log file scrubbed slightly to remove private data,
but still representative of the problem I believe.)
Nov 13 05:34:34 dev postgres[6084]: [4-1] user=dev,db=dev ERROR:
could not access status of transaction
Kevin Grittner kgri...@ymail.com writes:
If nobody objects, I'll fix that small memory leak in the
regression test driver. Hopefully someone more familiar with
pg_basebackup will fix the double-free (and related problems
mentioned by Tom) in streamutil.c.
Here's a less convoluted (IMHO)
Prevent excessive progress reporting that can grow to gigabytes
of output with large databases.
---
src/bin/pg_basebackup/pg_basebackup.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/src/bin/pg_basebackup/pg_basebackup.c
On 11/13/2013 11:37 AM, Merlin Moncure wrote:
Yes. and I think this is one of the major advantages of the json API
vs hstore: you can serialize objects that hstore cannot -- at least
not without extra scaffolding (at least, AIUI, I haven't fully
grappled with the coming hstore stuff yet). In
On 11/12/13, 1:35 PM, Teodor Sigaev wrote:
Attatched patch adds nesting feature, types (string, boll and numeric
values), arrays and scalar to hstore type.
Could you check your email client for next time? It's sending
Content-Type: application/x-tar for a *.patch.gz file.
--
Sent via
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 12, 2013 at 11:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Or we could say what the heck are you doing executing tens of
thousands of DO blocks? Make it into a real live function;
you'll save a lot of cycles on parsing costs. I'm not sure
On Tue, Nov 12, 2013 at 03:57:52PM +0900, Tatsuo Ishii wrote:
I have been thinking about this for years and I think the key idea for
this is, implementing universal encoding. The universal encoding
should have following characteristics to implement N2 encoding in a
database.
1) no loss of
When pg_upgrade generates a rebuild_tsvector_tables.sql script to
rewrite tsvector columns, it includes ALTER TABLE commands for child
tables that cannot be altered independently from their parents:
psql:rebuild_tsvector_tables.sql:673: ERROR: cannot alter inherited column
xxx
This isn't a
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Nov 12, 2013 at 03:57:52PM +0900, Tatsuo Ishii wrote:
Once we implement the universal encoding, other problem such as
pg_database with multiple encoding problem can be solved easily.
Isn't this essentially what the MULE internal
On 14/11/13 02:45, Peter Eisentraut wrote:
The commit fest manager mace has been passed on to me[*]. More to follow.
[*] Actually, I found it behind the dumpster in the alley.
Did you take care not to touch it with bare skin properly sterilize
it? As a used mace, may pick up blood from
As part of doing some database corruption investigation, I'm trying to get the
pg_clog/ bit pair for a particular transaction.
Let's say we check on a particular tuple, and get:
SELECT xmin, id FROM mytable WHERE pk=4727366;
xmin|id
---+--
107898222 | 4727366
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan and...@dunslane.net wrote:
On 11/13/2013 11:37 AM, Merlin Moncure wrote:
Yes. and I think this is one of the major advantages of the json API
vs hstore: you can serialize objects that hstore cannot -- at least
not without extra scaffolding (at
On 11/9/13, 5:56 AM, Andres Freund wrote:
ISTM ecpg's regression tests should be built (not run!) during
$(recurse) not just during make check.
Actually, I did just the opposite change some years ago. The rationale
is, the build builds that which you want to install.
--
Sent via
On Wed, Oct 23, 2013 at 8:52 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hmm, now if we had portable atomic addition, so that we could spare the
spinlock ...
That certainly seems like an interesting possibility.
I think that pg_stat_statements should be made to do this kind of
thing by
On 11/13/2013 06:45 AM, Merlin Moncure wrote: I'm not so sure we should
require hstore to do things like build
Also, json_object is pretty weird to me, I'm not sure I see the
advantage of a new serialization format, and I don't agree with the
statement but it is the caller's reponsibility to
On 11/13/2013 04:58 PM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan and...@dunslane.net wrote:
On 11/13/2013 11:37 AM, Merlin Moncure wrote:
Yes. and I think this is one of the major advantages of the json API
vs hstore: you can serialize objects that hstore cannot
On 14/11/13 11:33, Andrew Dunstan wrote:
On 11/13/2013 04:58 PM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan and...@dunslane.net
wrote:
On 11/13/2013 11:37 AM, Merlin Moncure wrote:
Yes. and I think this is one of the major advantages of the json API
vs hstore: you
Isn't this essentially what the MULE internal encoding is?
No. MULE is not powerfull enough and overly complicated to deal with
different encodings (character sets).
Currently there's no such an universal encoding in the universe, I
think the only way is, inventing it by ourselves.
This
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/13/2013 06:45 AM, Merlin Moncure wrote: I'm not so sure we should
require hstore to do things like build
Also, json_object is pretty weird to me, I'm not sure I see the
advantage of a new serialization format, and I
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus j...@agliodbs.com wrote:
Putting it all together, I'd consider:
*) dropping json_object (although maybe there is a case I'm not
thinking about)
*) changing json_build function names to get the json prefix
*) adding a json object
Merlin,
I use pg/JSON all over the place. In several cases I have to create
documents with ordered keys because the parser on the other side wants
them that way -- this is not a hypothetical argument. The current
json serialization API handles that just fine and the hstore stuff
coming
handyrep@john:~/handyrep$ pg_isready --version
pg_isready (PostgreSQL) 9.3.1
handyrep@john:~/handyrep$ pg_isready -h john -p 5432 -U postgres -d
postgres -q
pg_isready: missing = after postgres in connection info string
handyrep@john:~/handyrep$ pg_isready --host=john --port=5432
This is my first attempt at writing a patch, so it's pretty simple.
Commit log sums it up:
Adds a convenience feature to the explain command which prints out GUC cost
parameters in explain text output.
For example:
explain (params) select * from table;
will include text output
On 11/13/2013 01:37 AM, Andrew Dunstan wrote:
On 11/12/2013 01:35 PM, Teodor Sigaev wrote:
Hi!
Attatched patch adds nesting feature, types (string, boll and numeric
values), arrays and scalar to hstore type.
All new features are described in PGConf.EU talk
On 11/14/2013 12:09 AM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/13/2013 06:45 AM, Merlin Moncure wrote: I'm not so sure we should
require hstore to do things like build
Also, json_object is pretty weird to me, I'm not sure I see the
* Robert Berry (berrydigi...@gmail.com) wrote:
This is my first attempt at writing a patch, so it's pretty simple.
Neat!
seq_page: 1.00, rnd_page: 4.00, cpu_tup: 0.01,
cpu_ind: 0.005000, cpu_op: 0.002500
amenabled: 111
The bit vector is
Stephen Frost wrote
* Robert Berry (
berrydigital@
) wrote:
This is my first attempt at writing a patch, so it's pretty simple.
Neat!
seq_page: 1.00, rnd_page: 4.00, cpu_tup: 0.01,
cpu_ind: 0.005000, cpu_op: 0.002500
amenabled: 111
MULE is completely evil.
It has N different encodings for the same
character,
What's wrong with that? It aims that in the first place.
not to mention no support code available.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:
Tatsuo Ishii is...@postgresql.org writes:
MULE is completely evil.
It has N different encodings for the same character,
What's wrong with that? It aims that in the first place.
It greatly complicates comparisons --- at least, if you'd like to preserve
the principle that strings that appear
Snowman --
Thanks for feedback. I imagined this feature could be useful in a couple
of contexts, though mainly in the sense of documenting query optimization
efforts.
In one case you may be tweaking cost parameters and having a built in
record of the parameters in the explain output can make
On Nov 13, 2013, at 3:59 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
I remember strong voices in support of *not* normalising json, so that
things like
{a:1,a:true, a:b, a:none}
would go through the system unaltered, for claimed standard usage of
json as
processing instructions. That
On Nov 13, 2013, at 2:41 PM, Gavin Flower gavinflo...@archidevsys.co.nz wrote:
Would be possible to have a boolean, such as 'strict' - so that unique
ordered was only imposed when strict was TRUE? Alternately, separate
functions to allow the same choice?
It should be a pretty-printing
On 11/13/2013 07:01 PM, Hannu Krosing wrote:
I guess we should not replace current JSON type with hstore based
one, but add something json-like based on nested hstore instead.
Well, that's two voices for that course of action.
Interesting that I don't think I heard a single voice for this
Tatsuo Ishii is...@postgresql.org writes:
MULE is completely evil.
It has N different encodings for the same character,
What's wrong with that? It aims that in the first place.
It greatly complicates comparisons --- at least, if you'd like to preserve
the principle that strings that
On 11/13/2013 07:39 PM, David E. Wheeler wrote:
On Nov 13, 2013, at 2:41 PM, Gavin Flower gavinflo...@archidevsys.co.nz wrote:
Would be possible to have a boolean, such as 'strict' - so that unique
ordered was only imposed when strict was TRUE? Alternately, separate functions to
allow the
On Nov 13, 2013, at 4:45 PM, Andrew Dunstan and...@dunslane.net wrote:
It should be a pretty-printing function option, perhaps, but not core to the
type itself, IMO.
I don't in the least understand how it could be a pretty printing option. If
we move to a binary rep using the hstore stuff
Iy
On Thu, Nov 14, 2013 at 3:51 AM, Mika Eloranta m...@ohmu.fi wrote:
Prevent excessive progress reporting that can grow to gigabytes
of output with large databases.
It might be interesting to add this patch to the next commit fest
where you could get a formal review:
Reminder: Commit fest 2013-11, the third commit fest (out of four) in
the PostgreSQL development cycle, will start this Friday, November 15.
If you have a patch that you would like to see considered for inclusion
into PostgreSQL 9.4, please register it in the commit fest application
before Friday:
Tatsuo Ishii is...@postgresql.org writes:
BTW, same characters are assigned different code points are pretty
common in many character sets (Unicode, for example).
This is widely considered a security bug; read section 10 in RFC 3629 (the
definition of UTF8), and search the CVE database a bit if
On Wed, Nov 13, 2013 at 3:42 AM, Peter Eisentraut pete...@gmx.net wrote:
When an external recovery command such as restore_command or
archive_cleanup_command fails, it just reports return code 34567 or
something, but we have facilities to do decode this properly, so use
them.
I think this is
On Tue, 2013-11-12 at 17:48 +0900, Kyotaro HORIGUCHI wrote:
Hello, this is the revised patch.
Since you're using git, please check your patch for trailing whitespace
with git diff --check.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, 2013-11-13 at 17:25 +0900, Kyotaro HORIGUCHI wrote:
Added explicit cast there and rebased to current master.
Checked no new warning by this patch.
make check succeeded at both $(src) and $(src)/src/test.
This patch also has whitespace errors detected by git diff --check.
--
Sent
On Fri, 2013-11-08 at 10:01 -0500, Nigel Heron wrote:
here's v4 of the patch. I added documentation and a new global view
called pg_stat_socket (includes bytes_sent, bytes_received and
stats_reset time)
Your patch needs to be rebased:
CONFLICT (content): Merge conflict in
On Wed, 2013-10-09 at 18:57 +0200, Pavel Stehule wrote:
here is a patch for RAISE WHEN clause
Your patch needs to be rebased.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi hackers,
I'd like to propose adding inheritance support for foriegn tables.
David Fetter mentioned this feature last July, but it seems stalled.
http://www.postgresql.org/message-id/20130719005601.ga5...@fetter.org
Supporting inheritance by foreign tables allows us to distribute query
to
Shigeru Hanada shigeru.han...@gmail.com writes:
I'd like to propose adding inheritance support for foriegn tables.
David Fetter mentioned this feature last July, but it seems stalled.
http://www.postgresql.org/message-id/20130719005601.ga5...@fetter.org
The discussion there pointed out that
Hi,
I am struggling to understand what following phrase says:
tcp_keepalives_idle (integer)
Specifies the number of seconds before sending a keepalive packet
on an otherwise idle connection.
What I am not sure is the meaning of otherwise. Can I safely replace
it to:
Specifies the
1 - 100 of 108 matches
Mail list logo
