On Wed, Nov 13, 2013 at 2:42 AM, Craig Ringer 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 tree index alg
On Wed, Nov 13, 2013 at 1:22 PM, Luca Ferrari 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 be when a col
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'
2013/11/12 Claudio Freire :
> On Tue, Nov 12, 2013 at 6:41 PM, Nicolas Barbier
> 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 for the first level (of size S) can be
>
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 ne
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 b/src/backend/optimize
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 populat
On 12 November 2013 19:54, Claudio Freire wrote:
> On Tue, Nov 12, 2013 at 7:14 PM, Simon Riggs 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 well optimised by minmax indexes, or
2013/11/12 Simon Riggs :
> On 12 November 2013 21:41, Nicolas Barbier 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 contain data.
Under the assumption tha
Simon Riggs wrote
> On 5 November 2013 14:28, Leonardo Francalanci <
> m_lists@
> > 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
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
[ WITH [ RECUR
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 ref/
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
> 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 a
On 13 November 2013 06:07, Leonardo Francalanci 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).
> Keep the d
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 ever
On Wed, Nov 13, 2013 at 9:00 AM, Andres Freund 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 TABLE foo(cola int
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
--
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 Eisentra
On 1 August 2013 01:53, Noah Misch 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 to retain a co
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:
http://www.postgresql.org/mailpref/pgsql-
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
>
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 log
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 th
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. I
Peter Eisentraut 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 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 suitability of any in
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 inconve
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 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 PostgreSQL Company
On Wed, Nov 13, 2013 at 4:05 PM, Haribabu kommi
wrote:
> On 01 October 2013 00:56 Amit Kapila wrote:
>> On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut
>> 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:
>> >
>>
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
don
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 (pgsql-hack
On Wed, Nov 13, 2013 at 10:27 PM, Tom Lane wrote:
> Peter Eisentraut 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
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
> att
On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer 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 the v2 deve
On Wed, Nov 13, 2013 at 7:33 AM, Simon Riggs wrote:
> On 13 November 2013 09:31, Leonardo Francalanci 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
> MinMax 11 s
> Btree 96s
>
> Inde
On 13 November 2013 11:54, Merlin Moncure wrote:
> On Wed, Nov 13, 2013 at 7:33 AM, Simon Riggs wrote:
>> On 13 November 2013 09:31, Leonardo Francalanci 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.
On 13 November 2013 11:54, Merlin Moncure 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 larger. Which is
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 t
On Wed, Nov 13, 2013 at 08:58:07AM +0530, Amit Kapila wrote:
> On Tue, Nov 12, 2013 at 9:37 PM, Bruce Momjian 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
> >> wrote:
> >> > Hi,
> >> >
> >> > I would like to implem
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 whe
On 11/13/2013 09:45 AM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer 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 wo
Tom Lane 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 either way in th
On Mon, Nov 11, 2013 at 4:34 PM, Andres Freund 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 out one by one in
On Tue, Nov 12, 2013 at 09:55:34AM -0500, Robert Haas wrote:
> On Fri, Nov 8, 2013 at 4:13 PM, Noah Misch 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 best solu
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
> > wrote:
> > > Completely agreed. As evidenced by the fact that the current change
> > > doesn't update all relevant comments & code. I wonde
On Mon, Nov 11, 2013 at 11:10 PM, Craig Ringer 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,
> as doing so wo
On Wed, Nov 13, 2013 at 9:32 AM, Andrew Dunstan 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 (de-)serialize).
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 63
Kevin Grittner 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) approach to the pa
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
b/src/bin/pg_basebackup/pg_bas
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 pgsq
Robert Haas writes:
> On Tue, Nov 12, 2013 at 11:18 AM, Tom Lane 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 that
>> this is a usage pattern
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 N>2 encoding in a
> database.
>
> 1) no l
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 pr
Martijn van Oosterhout 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 encoding is?
MUL
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 p
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
E
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan 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 least, AIUI
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 pgsql-hack
On Wed, Oct 23, 2013 at 8:52 PM, Alvaro Herrera
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 a third party tool that
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 t
On 11/13/2013 04:58 PM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan 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 with
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
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 objec
> 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.
>
> T
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus 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 don't agree w
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus 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 constructor that t
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
> comin
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
--user=post
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 like
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
>> http://www.sai.ms
On 11/14/2013 12:09 AM, Merlin Moncure wrote:
> On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus 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
>>> advantag
* 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
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: 1
> 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: http://www.sraoss.c
Tatsuo Ishii 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 the same are equal
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 tha
On Nov 13, 2013, at 3:59 PM, Hannu Krosing 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 i
On Nov 13, 2013, at 2:41 PM, Gavin Flower 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 function option, perhaps, but
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 e
> Tatsuo Ishii 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 the s
On 11/13/2013 07:39 PM, David E. Wheeler wrote:
On Nov 13, 2013, at 2:41 PM, Gavin Flower 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
On Nov 13, 2013, at 4:45 PM, Andrew Dunstan 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 order will b
Iy
On Thu, Nov 14, 2013 at 3:51 AM, Mika Eloranta 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:
https://commitfest.postgresql.org/act
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 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 you still doubt
it
On Wed, Nov 13, 2013 at 3:42 AM, Peter Eisentraut 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 a very goo
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 subscri
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 src/test/regress
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 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 not enough considerati
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 n
1 - 100 of 108 matches
Mail list logo
