On 04/22/2014 05:20 PM, Josh Berkus wrote:
On 04/22/2014 02:01 PM, Alvaro Herrera wrote:
I think I should push this patch first, so that Andrew and Josh can try
their respective test cases which should start throwing errors, then
push the actual fixes. Does that sound okay?
Note that I have
On 04/22/2014 06:43 PM, Mark Wong wrote:
On Tue, Apr 22, 2014 at 10:06 AM, Joshua D. Drake
j...@commandprompt.com mailto:j...@commandprompt.com wrote:
On 04/22/2014 08:26 AM, Andrew Dunstan wrote:
I'm going away tomorrow for a few days RR. when I'm back next
week I
On 04/21/2014 11:39 AM, Magnus Hagander wrote:
On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund and...@2ndquadrant.com
mailto:and...@2ndquadrant.com wrote:
On 2014-04-21 10:45:24 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com
mailto:and...@2ndquadrant.com writes:
On 04/21/2014 11:59 AM, Alfred Perlstein wrote:
On 4/21/14 8:45 AM, Andrew Dunstan wrote:
On 04/21/2014 11:39 AM, Magnus Hagander wrote:
On Mon, Apr 21, 2014 at 4:51 PM, Andres Freund
and...@2ndquadrant.com mailto:and...@2ndquadrant.com wrote:
On 2014-04-21 10:45:24 -0400, Tom Lane
On 04/21/2014 12:25 PM, Alfred Perlstein wrote:
1. OS developers are not the target audience for GUCs. If the OS
developers want to test and can't be botherrd with building with a
couple of different parameters then I'm not very impressed.
2. We should be trying to get rid of GUCs
On 04/21/2014 12:44 PM, Alfred Perlstein wrote:
On 4/21/14 9:38 AM, Andrew Dunstan wrote:
On 04/21/2014 12:25 PM, Alfred Perlstein wrote:
1. OS developers are not the target audience for GUCs. If the OS
developers want to test and can't be botherrd with building with a
couple
On 04/21/2014 03:26 PM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I spent the last two hours poking arounds in the environment Andrew
provided and I was able to reproduce the issue, find a assert to
reproduce it much faster and find a possible root cause.
Hmm ... is this the
On 04/21/2014 02:54 PM, Andres Freund wrote:
Hi,
I spent the last two hours poking arounds in the environment Andrew
provided and I was able to reproduce the issue, find a assert to
reproduce it much faster and find a possible root cause.
What's the assert that makes it happen faster? That
On 04/21/2014 08:49 PM, Stephen Frost wrote:
* Tatsuo Ishii (is...@postgresql.org) wrote:
I observe performance degradation with PostgreSQL 9.3 vs 9.2 on Linux
as well. The hardware is HP DL980G7, 80 cores, 2TB mem, RHEL 6,
pgbench is used (read only query), scale factor is 1,000 (DB size
On 04/21/2014 09:16 PM, Peter Geoghegan wrote:
On Mon, Apr 21, 2014 at 6:08 PM, Tatsuo Ishii is...@postgresql.org wrote:
What we would need is a way to graph the results - that's something
beyond my very rudimentary expertise in web programming. If anyone
feels like collaborating I'd be glad
On 04/17/2014 10:15 AM, Andrew Dunstan wrote:
On 04/16/2014 10:28 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/16/2014 07:19 PM, Tom Lane wrote:
Yeah, it would be real nice to see a self-contained test case for
this.
Well, that might be hard to put together, but I
On 04/16/2014 10:28 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/16/2014 07:19 PM, Tom Lane wrote:
Yeah, it would be real nice to see a self-contained test case for this.
Well, that might be hard to put together, but I did try running without
pg_stat_statements
On 04/17/2014 09:17 AM, Robert Haas wrote:
In terms of improving the buildfarm infrastructure, the thing I would
most like to have is more frequent runs. It would be great if pushing
a commit to the master repository triggered an immediate build on
every buildfarm animal so that you could
On 04/17/2014 09:04 PM, Peter Geoghegan wrote:
On Thu, Apr 17, 2014 at 7:15 AM, Andrew Dunstan and...@dunslane.net wrote:
track_activity_query_size = 10240
shared_preload_libraries = 'auto_explain,pg_stat_statements'
As you can see, auto_explain's log_min_duration hasn't been set, so
On 04/16/2014 07:19 PM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I'm not quite clear on why the third query, the one in ri_PerformCheck,
is invoking a sequence.
It's not --- SeqNext is the next-tuple function for a sequential scan.
Nothing to do with sequences.
Now, it
On 04/15/2014 06:26 PM, Thom Brown wrote:
On 15 April 2014 23:19, Andreas 'ads' Scherbaum adsm...@wars-nicht.de wrote:
Hi,
stumbled over a number of iff in the source where if is meant - not sure
what the real story behind this is, but attached is a patch to fix the about
80 occurrences.
With a client's code I have just managed to produce the following
assertion failure on 9.3.4:
2014-04-15 01:02:46 GMT [19854] 76299: LOG: execute unnamed:
select * from asp_ins_event_task_log( job_id:=1, event_id:=3164,
task_name:='EventUtcComputeTask', task_status_code:='VALID'
On 04/14/2014 09:28 PM, Andrew Dunstan wrote:
With a client's code I have just managed to produce the following
assertion failure on 9.3.4:
2014-04-15 01:02:46 GMT [19854] 76299: LOG: execute unnamed:
select * from asp_ins_event_task_log( job_id:=1, event_id:=3164,
task_name
On 04/14/2014 10:02 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
and here the stack trace:
#0 0x00361ba36285 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00361ba37b9b in __GI_abort () at abort.c:91
#2 0x0075c157
On 04/14/2014 10:17 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Add TAP tests for client programs
I assume the buildfarm would need to be taught about this?
Yes. It probably won't be a huge change, but it will need a bit of code.
cheers
andrew
On 04/14/2014 10:30 PM, Andrew Dunstan wrote:
On 04/14/2014 10:17 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Add TAP tests for client programs
I assume the buildfarm would need to be taught about this?
Yes. It probably won't be a huge change, but it will need a bit
On 04/12/2014 12:39 PM, Marco Atzeri wrote:
Anyone seeing similar failure ?
testing on latest
$ git log |head
commit 3c41b812c5578fd7bd5c2de42941012d7d56dde2
Author: Bruce Momjian br...@momjian.us
Date: Thu Apr 10 17:16:22 2014 -0400
docs: psql '--' comments are not passed to the
On 04/11/2014 01:35 AM, Amit Kapila wrote:
On Fri, Apr 11, 2014 at 3:14 AM, Bruce Momjian br...@momjian.us wrote:
Can someone with Windows expertise comment on whether this should be
applied?
I don't think this is a complete fix, for example what about platform where
_CreateRestrictedToken()
On 04/10/2014 09:13 AM, Olivier Lalonde wrote:
I was wondering if there would be any way to do the following in
PostgreSQL:
UPDATE cryptotable SET work = work + 'some big hexadecimal number'
where work is an unsigned 256 bit integer. Right now my column is a
character varying(64) column
On 04/08/2014 05:57 PM, Peter Geoghegan wrote:
On Tue, Apr 8, 2014 at 2:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, let me see if I understand the situation correctly:
* jsonb_ops supports more operators
* jsonb_hash_ops produces smaller, better-performing indexes
* jsonb_ops falls over
On 04/06/2014 12:06 PM, Tom Lane wrote:
I'd been getting weird results for the last couple of days while
pgindent-ing various patches. I eventually realized that the cause
was that the current typedefs list marks c, string, and a few
other common words as typedefs. This seems pretty uncool.
I had a look at extending the MSVC build system to support the
test_decoding module. Unfortunately, it requires use of --extra-install
which isn't supported on non-make systems. I'm not going to support that
now - it's a fairly ugly wart but addressing it would take far more time
than I have
I have released version 4.12 of the buildfarm client.
In addition to numerous bug fixes, it has the following:
* the global option branches_to_build can now be HEADPLUSLATESTn' for
any single digit n
* there is a new module TestCollateLinuxUTF8
* there is a new module TestDecoding which
On 04/03/2014 05:02 AM, Oleg Bartunov wrote:
Well, we don't supported Infinity and NaN in json(b), as well as Json
standard :)
Now we need a script, which generated nice html table.
(Oleg, please try not to top-post.)
I don't think we should follow these rules at all. Json is not
On 04/03/2014 12:01 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
For OSX we'd construct the list via File::Find to recurse through the
directories.
So, something like this:
Thanks for the tips. The attached patch against buildfarm 4.11 seems
to work, cf
http
On 03/27/2014 01:09 PM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Note that make check in contrib is substantially slower than make
installcheck --- it creates a temporary installation for each contrib
module. If we make buildfarm run installcheck for all modules, that
On 04/02/2014 12:25 AM, Andrew Dunstan wrote:
On 04/01/2014 09:22 PM, Andrew Dunstan wrote:
On 04/01/2014 08:53 PM, Tom Lane wrote:
The current typedefs list seems to be lacking any Windows-only
typedefs.
Noticed while trying to pgindent postmaster.c.
Hmm. odd. will check.
It's
On 04/02/2014 08:43 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
BTW, three animals are currently trying to contribute typedefs but
aren't in fact contributing anything: okapi, dromedary and prairiedog.
See http://www.pgbuildfarm.org/cgi-bin/typedefs.pl?show_list=1
Man
On 04/01/2014 10:45 AM, Fabien COELHO wrote:
Hello pgdevs,
I noticed that my pg_stat_statements is cluttered with hundreds of
entries like DEALLOCATE dbdpg_p123456_7, occuring each only once.
It seems to me that it would be more helful if these similar entries
where aggregated together,
On 04/01/2014 03:40 PM, Jim Nasby wrote:
On 3/18/14, 12:13 PM, Greg Stark wrote:
Fwiw I'm finding myself repeatedly caught up by the operator
precedence rules when experimenting with jsonb:
stark=***# select segment-'id' as id from flight_segments where
segment-'marketing_airline_code'
On 04/01/2014 05:42 PM, Jim Nasby wrote:
On 4/1/14, 3:07 PM, Andrew Dunstan wrote:
What are cases where things would break if we changed the precedence
of - and -? ISTM that's what we really should do if there's some
way to manage the backwards compatibility...
There is no provision
On 04/01/2014 08:53 PM, Tom Lane wrote:
The current typedefs list seems to be lacking any Windows-only typedefs.
Noticed while trying to pgindent postmaster.c.
Hmm. odd. will check.
cheers
andrew
--
Sent via pgsql-hackers mailing list
On 04/01/2014 09:22 PM, Andrew Dunstan wrote:
On 04/01/2014 08:53 PM, Tom Lane wrote:
The current typedefs list seems to be lacking any Windows-only typedefs.
Noticed while trying to pgindent postmaster.c.
Hmm. odd. will check.
It's apparently causing the buildfarm to crash, which
On 03/31/2014 10:18 AM, steve k wrote:
http://postgresql.1045698.n5.nabble.com/file/n5798002/PG_man_excerpt.png
These were my results:
http://postgresql.1045698.n5.nabble.com/file/n5798002/PG_embedded_copy_log_excerpt.png
I'd advise anyone contemplating using this feature to seriously
make check in contrib/test_decoding actually does two regression runs,
one with pg_regress and one with pg_isolation_regress. These both use
the same (default) outputdir, so one overwrites the other, which is a
bit unfortunate from the buildfarm's point of view. I propose to make
them use
On 03/29/2014 04:49 PM, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
As my belief is that 99% of the uses of \d are for human consumption
(because machines should in most cases hit the catalogs directly) then
strictly displaying Includes OIDs when
On 03/29/2014 06:10 PM, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 05:10:49PM -0400, Andrew Dunstan wrote:
On 03/29/2014 04:49 PM, Bruce Momjian wrote:
On Sat, Mar 29, 2014 at 09:59:36AM -0700, David Johnston wrote:
As my belief is that 99% of the uses of \d are for human consumption
On 03/27/2014 10:13 AM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
I meant to say what's actually in git HEAD at the moment is broken.
Uh, I thought that might be what you were saying, but I am not seeing
any
On 03/27/2014 10:31 AM, Andrew Dunstan wrote:
On 03/27/2014 10:13 AM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Mar 27, 2014 at 02:41:40PM +0100, Christoph Berg wrote:
I meant to say what's actually in git HEAD at the moment is broken.
Uh, I thought that might be what
On 03/27/2014 11:27 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I guess we'd better add a make-contrib-check step to the buildfarm. I
was just prepping a release, so I'll delay that while I add this.
BTW, won't that obsolete the need for the separate check-pg_upgrade
step
On 03/27/2014 11:34 AM, Christoph Berg wrote:
Re: Andrew Dunstan 2014-03-27 53344465.6010...@dunslane.net
On 03/27/2014 11:27 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I guess we'd better add a make-contrib-check step to the buildfarm. I
was just prepping a release, so
On 03/27/2014 11:56 AM, Alvaro Herrera wrote:
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar treatment, it's not looking so good.
Should we consider redoing that stuff in a way that
On 03/27/2014 04:31 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 03/27/2014 11:56 AM, Alvaro Herrera wrote:
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar
On 03/27/2014 04:43 PM, David Johnston wrote:
Bruce Momjian wrote
When we made OIDs optional, we added an oid status display to \d+:
test= \d+ test
Table public.test
Column | Type | Modifiers | Storage | Stats target | Description
On 03/27/2014 05:15 PM, Andres Freund wrote:
On 2014-03-27 12:56:02 -0300, Alvaro Herrera wrote:
Also, there's the vcregress.pl business. The way it essentially
duplicates pg_upgrade/test.sh is rather messy; and now that
test_decoding also needs similar treatment, it's not looking so good.
On 03/26/2014 11:37 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
It occurred to me after having to change I think 9 files to clean up a
small mess in the jsonb regression tests the other day that we might
usefully expose the inputdir and outputdir to psql as variables when
On 03/26/2014 05:01 PM, Peter Geoghegan wrote:
I found another bug of this category using Valgrind (memcheck). When
the standard regression tests are run against master's git tip, I see
the following:
2014-03-26 12:58:21.246 PDT 28882 LOG: statement: select * from
It occurred to me after having to change I think 9 files to clean up a
small mess in the jsonb regression tests the other day that we might
usefully expose the inputdir and outputdir to psql as variables when
running pg_regress. Then we might be able to do thing like this, quite
independent of
On 03/24/2014 02:50 PM, Jim Nasby wrote:
On 3/22/14, 11:26 AM, Jim Nasby wrote:
On 3/21/14, 4:54 PM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
There is no way for psql to handle that case though unless you'd strip
*all* BOMs encountered. Compounding this problem is that
On 03/24/2014 08:28 PM, Tatsuo Ishii wrote:
The code would probably be pretty trivial, *if* we had consensus on
what the behavior ought to be. I'm not sure if we do. People who
only use Unicode would probably like it if BOMs were unconditionally
swallowed, whether or not psql thinks the
On 03/21/2014 09:38 AM, Robert Haas wrote:
On Thu, Mar 20, 2014 at 11:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Craig Ringer cr...@2ndquadrant.com writes:
Here's how I think it needs to look:
[ move all the functionality to the backend ]
Of course, after you've done all that work, you've got
On 03/21/2014 05:06 PM, Merlin Moncure wrote:
On Fri, Mar 21, 2014 at 4:02 PM, Jim Nasby j...@nasby.net wrote:
See http://www.postgresql.org/message-id/4afeab39.3000...@dunslane.net
This is still broken as of fairly recent HEAD; any objections to adding it to
TODO?
Agreed: this is a major
On 03/19/2014 03:58 PM, Peter Geoghegan wrote:
On Wed, Mar 19, 2014 at 9:28 AM, Andres Freund and...@2ndquadrant.com wrote:
* Jsonb vs JsonbValue is just bad, the latter needs to be renamed, and
there needs to be a very clear explanation about why two forms exist
and what each is used
On 03/19/2014 06:57 PM, Peter Geoghegan wrote:
On Wed, Mar 19, 2014 at 9:28 AM, Andres Freund and...@2ndquadrant.com wrote:
* Jsonb vs JsonbValue is just bad, the latter needs to be renamed, and
there needs to be a very clear explanation about why two forms exist
and what each is used
On 03/17/2014 10:31 PM, Peter Eisentraut wrote:
On Sun, 2014-03-16 at 22:34 -0400, Tom Lane wrote:
As for 2.4 vs 2.5, I don't have a lot of faith that we're really
supporting anything that's not represented in the buildfarm...
There are many other features that the build farm doesn't test and
On 03/18/2014 04:39 PM, Andres Freund wrote:
Mail that's CC/TOed to me onlist, is automatically marked as read by a
sieve script so I don't have to mark it as read twice. It seems
something went wrong there for a couple of messages...
Why not just turn on eliminatecc on the majordomo
On 03/16/2014 04:10 AM, Peter Geoghegan wrote:
On Thu, Mar 13, 2014 at 2:00 PM, Andrew Dunstan and...@dunslane.net wrote:
I'll be travelling a good bit of tomorrow (Friday), but I hope Peter has
finished by the time I am back on deck late tomorrow and that I am able to
commit this on Saturday
On 03/13/2014 06:53 AM, Greg Stark wrote:
I also find it awkward that col-'prop' returns the json
representation of the property. If it's text that means it's
double-quoted. I would think that a user storing text in a json
property would want a way to pull out the text that json property
On 03/13/2014 08:42 AM, Greg Stark wrote:
Fwiw the jsonb data doesn't actually seem to be any smaller than text
json on this data set (this is avg(pg_column_size(col)) and I checked,
they're both using the same amount of toast space)
jsonb | json
---+---
813.5 | 716.3
(1 row)
On 03/13/2014 10:49 AM, Greg Stark wrote:
Another question. Is Peter's branch up to date with
jsonb_populate_record() ? From discussions on list it sounds like the
plan was to get rid of the use_json_as_text argument but his patch
still has it.
Yes, we're not changing that, and some people
On 03/13/2014 11:27 AM, Ashoke wrote:
Hi,
Thanks for the input. I would look into JSON parsing as well, but
the requirement is XML parsing.
There is no DTD/Schema for the XML. Is there any way I could know
what are the possible tags and their values? I am building my parser
based on
On 03/13/2014 01:01 PM, Josh Berkus wrote:
On 03/13/2014 09:53 AM, Ryan Pedela wrote:
This is my first email to the PostgreSQL mailing lists so I hope this is
the correct place. If not, please let me know.
I was wondering if it would be possible and wise to support JSON Patch?
Peter Geoghegan has been doing a lot of great cleanup of the jsonb code,
after moving in the bits we wanted from nested hstore. You can see the
current state of the code at
https://github.com/feodor/postgres/tree/jsonb_and_hstore
I've been working through some of his changes, I will
On 03/12/2014 09:36 AM, Ashoke wrote:
Hi,
I am working on adding a functionality to PostgreSQL. I need to
parse the XML format query plan (produced by PostgreSQL v9.3) and save
it in a simple data structure (say C structure). I was wondering if
PostgreSQL already had any parsing
On 03/12/2014 02:09 PM, Josh Berkus wrote:
On 03/12/2014 12:22 AM, Magnus Hagander wrote:
On Mar 12, 2014 1:46 AM, Josh Berkus j...@agliodbs.com wrote:
Yeah, what we really need is encapsulated per-DB users and local
superusers. I think every agrees that this is the goal, but nobody
wants to
On 03/12/2014 04:10 PM, Peter Geoghegan wrote:
On Wed, Mar 12, 2014 at 11:57 AM, Oleg Bartunov obartu...@gmail.com wrote:
Also, GiST index is faster for create/update operations. I really hope we will
improve jsonb indexing in the next one-two releases. For now I'd suggest people
index
On 03/12/2014 04:58 PM, Peter Geoghegan wrote:
In any case, let's focus on what we have right now. I think that the
indexing facilities proposed here are solid. In any case they do not
preclude working on better indexing strategies as the need emerges.
I quite agree, didn't mean to suggest
On 03/11/2014 09:57 AM, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Mar 11, 2014 at 2:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Are you claiming there are no users, and if so, on what evidence?
I am claiming that I don't think anybody is using that, yes.
Based on the
On 03/11/2014 12:37 PM, Stephen Frost wrote:
Isn't the other issue for ISPs essentially that we don't have row-level
security for our global catalogs? as in- we can't limit what's in
pg_authid to only those entries a given user should be able to see? I
don't think db_user_namespace addresses
On 03/11/2014 07:41 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The docs say:
db_user_namespace causes the client's and server's user name
representation to differ. Authentication checks are always done with
the server's user name so authentication methods
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar commands. This doesn't seem simple to
enforce (if we supported partial indexes on
On 03/11/2014 11:06 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 03/11/2014 09:37 PM, Tom Lane wrote:
In particular, I'd like to see an exclusion that prevents local users
from having the same name as any global user, so that we don't have
ambiguity in GRANT and similar
On 03/11/2014 11:50 PM, Jaime Casanova wrote:
On Tue, Mar 11, 2014 at 10:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But not sure how to define a unique
index that allows (joe, db1) to coexist with (joe, db2) but not with
(joe, 0).
and why you want that restriction? when you login you need to
On 03/10/2014 05:18 AM, Peter Geoghegan wrote:
On Fri, Mar 7, 2014 at 9:00 AM, Bruce Momjian br...@momjian.us wrote:
OK, it sounds like the adjustments are minimal, like not using the
high-order bit.
Attached patch is a refinement of the work of Oleg, Teodor and Andrew.
Revisions are mostly
On 03/10/2014 10:50 AM, Andrew Dunstan wrote:
Thanks for your work on this.
It's just occurred to me that we'll need to add hstore_to_jsonb
functions and a cast to match the hstore_to_json functions and cast.
That should be fairly simple - I'll work on that. It need not hold up
progress
On 03/06/2014 11:33 PM, Bruce Momjian wrote:
On Thu, Mar 6, 2014 at 09:50:56PM +0400, Oleg Bartunov wrote:
Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to the flagship feature
On 03/07/2014 11:45 AM, Bruce Momjian wrote:
On Fri, Mar 7, 2014 at 11:35:41AM -0500, Andrew Dunstan wrote:
IIRC The sacrifice was one bit in the header (i.e. in the first int
after the varlena header). We could now repurpose that (for example
if we ever decided to use a new format).
Oleg
On 03/06/2014 08:16 AM, Oleg Bartunov wrote:
On Thu, Mar 6, 2014 at 12:43 PM, Peter Geoghegan p...@heroku.com wrote:
On Thu, Mar 6, 2014 at 12:23 AM, Teodor Sigaev teo...@sigaev.ru wrote:
That's possible to introduce GUC variable for i/o functions which will
control old bug-to-bug behavior.
On 03/06/2014 10:46 AM, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
However, if the new hstore type (compatible with the old one) is the
wrapper around jsonb, rather than the other way around, I don't see any
problem with it at all. Most future users are almost certainly going
On 03/06/2014 12:50 PM, Oleg Bartunov wrote:
Hi there,
Looks like consensus is done. I and Teodor are not happy with it, but
what we can do :) One thing I want to do is to reserve our
contribution to the flagship feature (jsonb), particularly, binary
storage for nested structures and
On 03/05/2014 09:11 AM, Michael Paquier wrote:
After testing this feature, I noticed that FORCE_NULL and
FORCE_NOT_NULL can both be specified with COPY on the same column.
This does not seem correct. The attached patch adds some more error
handling, and a regression test case for that.
On 03/05/2014 09:39 AM, Bruce Momjian wrote:
So, I am going to ask a back-track question and ask why we can't move
hstore into core. Is this a problem with the oids of the hstore data
type and functions? Is this a pg_upgrade-only problem? Can this be
fixed?
Yes, pg_upgrade is the
On 03/05/2014 10:24 AM, Tom Lane wrote:
Also, there might be other cases besides arrays where we've embedded
type OIDs in on-disk data; anyone remember?
Don't we do that in composites too?
cheers
andrew
--
Sent via pgsql-hackers mailing list
On 03/05/2014 10:30 AM, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Also, there might be other cases besides arrays where we've embedded
type OIDs in on-disk data; anyone remember?
composite types.
But that's
On 03/05/2014 11:34 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Just out of curiosity, exactly what features are missing from jsonb
today that are available with hstore? How long would it take to
copy-and-paste all that code, if someone were to decide to do the
work
On 03/05/2014 11:44 AM, Bruce Momjian wrote:
On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
It seems only pg_type.oid is an issue for hstore. We can easily modify
pg_dump --binary-upgrade mode to suppress the creation of the hstore
extension.
On 03/05/2014 12:01 PM, Bruce Momjian wrote:
On Wed, Mar 5, 2014 at 11:53:31AM -0500, Andrew Dunstan wrote:
I think we also have to break out how much of the feeling that JSONB is
not ready is because of problems with the core/contrib split, and how
much of it is because of the type itself
On 03/04/2014 11:23 AM, Joel Jacobson wrote:
I understand that from a technical perspective, the mandatory
BEGIN...END you always need in a PL/pgSQL function, is a new block,
and the variables declared are perhaps technically in a new block, at
a deeper level than the IN/OUT variables. But I
On 03/04/2014 03:40 PM, Joel Jacobson wrote:
On Tue, Mar 4, 2014 at 8:04 PM, Andrew Dunstan and...@dunslane.net wrote:
Lots of code quite correctly relies on this,
including some I have written.
I really cannot see when it would be a good coding practise to do so,
there must be something I
On 03/03/2014 06:48 AM, Michael Paquier wrote:
On Mon, Mar 3, 2014 at 1:13 PM, Andrew Dunstan and...@dunslane.net wrote:
That difference actually made the file_fdw regression results plain
wrong,
in my view, in that they expected a quoted empty string to be turned to
null
even when the null
On 03/03/2014 02:00 AM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
The only way I can see this being of real use to an attacker is if they
could use this exploit to create a wormed version of PostgresQL on the
target build system. Is that possible?
It's theoretically possible,
On 03/03/2014 07:50 PM, Peter Geoghegan wrote:
On Fri, Feb 28, 2014 at 2:12 PM, Peter Geoghegan p...@heroku.com wrote:
In order to make a rational decision to do the work incrementally, we
need to know what we're putting off until 9.5. AFAICT, we have these
operator classes that work fine with
On 03/03/2014 10:39 PM, Peter Geoghegan wrote:
On Mon, Mar 3, 2014 at 6:54 PM, Andrew Dunstan and...@dunslane.net wrote:
My aim for 9.4, given constraints of both the development cycle and my time
budget, has been to get jsonb to a point where it has equivalent
functionality to json, so
On 03/03/2014 11:20 PM, Peter Geoghegan wrote:
On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus j...@agliodbs.com wrote:
Also, please recognize that the current implementation was what we
collectively decided on three months ago, and what Andrew worked pretty
hard to implement based on that
On 03/02/2014 01:27 PM, Tom Lane wrote:
Also, to what extent does any of this affect buildfarm animals? Whatever
we do for make check will presumably make those tests safe for them,
but how are the postmasters they test under make installcheck set up?
Nothing special.
bin/initdb -U
1101 - 1200 of 8267 matches
Mail list logo
