Re: [HACKERS] gaussian distribution pgbench

(2014/03/13 23:00), Fujii Masao wrote: On Thu, Mar 13, 2014 at 10:51 PM, Heikki Linnakangas wrote: On 03/13/2014 03:17 PM, Fujii Masao wrote: On Tue, Mar 11, 2014 at 1:49 PM, KONDO Mitsumasa wrote: (2014/03/09 1:49), Fabien COELHO wrote: I'm okay with this UI and itsaccess probability o

Re: [HACKERS] gaussian distribution pgbench

Hi, (2014/03/14 4:21), Fabien COELHO wrote: We should do the same discussion for the UI of command-line option? The patch adds two options --gaussian and --exponential, but this UI seems to be a bit inconsistent with the UI for \setrandom. Instead, we can use something like --distribution=[uni

[HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

Hi, In connection to my previous proposal about "providing catalog view to pg_hba.conf file contents" , I have developed the attached patch . [Current situation] Currently, to view the pg_hba.conf file contents, DB admin has to access the file from database server to read the settings. I

Re: [HACKERS] issue log message to suggest VACUUM FULL if a table is nearly empty

On Wed, Mar 12, 2014 at 12:22 PM, Haribabu Kommi wrote: > On Tue, Mar 11, 2014 at 2:59 PM, Amit Kapila wrote: > >> By the way have you checked if FreeSpaceMapVacuum() can serve your >> purpose, because this call already traverses FSM in depth-first order to >> update the freespace. So may be by u

Re: [HACKERS] requested shared memory size overflows size_t

On 03/04/2014 10:53 PM, Yuri Levinsky wrote: > Please advise me: I just downloaded the source and compiled it. Sun Spark > Solaris 9 is always 64 bit, I verified it with sys admin. He may run 32 bit > applications as well. Have I use some special option during compilation to > verify that compil

Re: [HACKERS] Replication slots and footguns

On 03/13/2014 05:28 PM, Robert Haas wrote: > Well we may have kind of hosed ourselves, because the in-memory data > structures that represent the data structure have an in_use flag that > indicates whether the structure is allocated at all, and then an > active flag that indicates whether some back

Re: [HACKERS] Replication slots and footguns

On Thu, Mar 13, 2014 at 8:09 PM, Josh Berkus wrote: > On 03/13/2014 05:01 PM, Robert Haas wrote: >> On Thu, Mar 13, 2014 at 6:45 PM, Josh Berkus wrote: >>> On 03/13/2014 01:17 PM, Robert Haas wrote: I think "in use" is just as clear as active, and I think the text Andres proposed previo

Re: [HACKERS] Replication slots and footguns

On 03/13/2014 05:01 PM, Robert Haas wrote: > On Thu, Mar 13, 2014 at 6:45 PM, Josh Berkus wrote: >> On 03/13/2014 01:17 PM, Robert Haas wrote: >>> I think "in use" is just as clear as active, and I think the text >>> Andres proposed previously reads a whole lot more nicely than this: >>> >>> repli

Re: [HACKERS] Replication slots and footguns

On Thu, Mar 13, 2014 at 6:45 PM, Josh Berkus wrote: > On 03/13/2014 01:17 PM, Robert Haas wrote: >> I think "in use" is just as clear as active, and I think the text >> Andres proposed previously reads a whole lot more nicely than this: >> >> replication slot "%s" is in use by another backend > >

Re: [HACKERS] Replication slots and footguns

On 03/13/2014 01:17 PM, Robert Haas wrote: > I think "in use" is just as clear as active, and I think the text > Andres proposed previously reads a whole lot more nicely than this: > > replication slot "%s" is in use by another backend Then we should change the column name in the pg_stat_replicat

Re: [HACKERS] jsonb and nested hstore

On Thu, Mar 13, 2014 at 2:21 AM, Greg Stark wrote: > It does sound like the main question here is which opclass should be > the default. From the discussion there's a jsonb_hash_ops which works > on all input values but supports fewer operators and a jsonb_ops which > supports more operators but c

Re: [HACKERS] Add CREATE support to event triggers

Alvaro Herrera escribió: > I also fixed the sequence OWNED BY problem simply by adding support for > ALTER SEQUENCE. Of course, the intention is that all forms of CREATE > and ALTER are supported, but this one seems reasonable standalone > because CREATE TABLE uses it internally. I have been hac

[HACKERS] jsonb status

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 I've been working through some of his changes, I will probab

Re: [HACKERS] jsonb and nested hstore

On Mon, Mar 10, 2014 at 4:18 AM, Peter Geoghegan wrote: > * Extensive additional documentation. References to the very new JSON > RFC. I think that this revision is in general a lot more coherent, and > I found that reflecting on what idiomatic usage should look like while > writing the documentat

Re: [HACKERS] jsonb and nested hstore

On 13.3.2014 13:28, Oleg Bartunov wrote: > On Thu, Mar 13, 2014 at 4:21 PM, Alexander Korotkov > wrote: >> On Thu, Mar 13, 2014 at 1:21 PM, Greg Stark wrote: >>> >>> Well these are just normal gin and gist indexes. If we want to come up >>> with new index operator classess we can still do that an

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 11:30 AM, Alvaro Herrera wrote: > Robert Haas escribió: >> Well, I don't have a big problem with the idea that some sessions >> might not have a certain extension loaded. For some extensions, that >> might not lead to very coherent behavior, but I guess it's the >> extensi

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 11:37 AM, Andres Freund wrote: >> I seriously doubt that's going to work nicely. Now you've implicitly >> introduced a dependency from every object that has a label to the >> label provider. pg_dump is going to have to restore the validator >> function before it restores

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 11:42 AM, Andres Freund wrote: > On 2014-03-13 11:26:10 -0400, Robert Haas wrote: >> On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane wrote: >> > If there's not a catcache for pg_seclabels, I'd have no objection >> > to adding one. As for your "userland cache" objection, you ce

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 12:11 PM, Tom Lane wrote: > Andres Freund writes: >> On 2014-03-13 11:26:10 -0400, Robert Haas wrote: >>> I have however had the thought before that it would be nice to allow >>> for callbacks of invalidation functions of some kind even on catalogs >>> that don't have catc

Re: [HACKERS] Replication slots and footguns

On Thu, Mar 13, 2014 at 1:03 PM, Josh Berkus wrote: > On 03/13/2014 04:07 AM, Andres Freund wrote: >> On 2014-03-12 13:34:47 -0700, Josh Berkus wrote: >>> On 03/12/2014 12:34 PM, Robert Haas wrote: >> Urgh. That error message looks susceptible to improvement. How about: rep

Re: [HACKERS] gaussian distribution pgbench

We should do the same discussion for the UI of command-line option? The patch adds two options --gaussian and --exponential, but this UI seems to be a bit inconsistent with the UI for \setrandom. Instead, we can use something like --distribution=[uniform | gaussian | exponential]. Hmmm. That

Re: [HACKERS] GIN improvements part2: fast scan

On Thu, Mar 13, 2014 at 8:58 PM, Heikki Linnakangas wrote: > On 03/12/2014 07:52 PM, Alexander Korotkov wrote: > >> > >>> >* I just noticed that the dummy trueTriConsistentFn returns GIN_MAYBE, >>> >rather than GIN_TRUE. The equivalent boolean version returns 'true' >>> without >>> >recheck. Is t

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

Rajeev rastogi writes: > [ updated patch ] I've committed this patch with additional revisions. > Based on my analysis, I observed that just file pointer comparison may not be > sufficient > to decide whether to display command tag or not. E.g. imagine below scenario: > psql.exe -d post

Re: [HACKERS] JSON Patch (RFC 6902) support?

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? https://tools.ie

Re: [HACKERS] 9a57858f1103b89a5674f0d50c5fe1f756411df6

On Thu, Mar 13, 2014 at 5:10 PM, Josh Berkus wrote: > First, I'll note that one of the reasons we haven't had a bunch of > reports from the field about this is that a lot of our users have yet to > apply 9.3.3, so if they have corruption issues they probably attribute > them to the issues which ar

Re: [HACKERS] 9a57858f1103b89a5674f0d50c5fe1f756411df6

All, First, I'll note that one of the reasons we haven't had a bunch of reports from the field about this is that a lot of our users have yet to apply 9.3.3, so if they have corruption issues they probably attribute them to the issues which are fixed in 9.3.3. I know that's the case with our cust

Re: [HACKERS] Proposal to join the hackers list

On 03/13/2014 08:54 AM, Rajashree Mandaogane wrote: > We have decided to modify the storage of PostgresSQL for columnar storage > along with row based tuple storage. We are trying to modify the planner and > optimiser to generate the plan using data stored in both both row and > columnar storage. W

Re: [HACKERS] Replication slots and footguns

On 03/13/2014 04:07 AM, Andres Freund wrote: > On 2014-03-12 13:34:47 -0700, Josh Berkus wrote: >> On 03/12/2014 12:34 PM, Robert Haas wrote: > Urgh. That error message looks susceptible to improvement. How about: >>> >>> replication slot "%s" cannot be dropped because it is currently

Re: [HACKERS] JSON Patch (RFC 6902) support?

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? > https://tools.ietf.org/html/rfc6902 > > One of the p

Re: [HACKERS] GIN improvements part2: fast scan

On 03/12/2014 07:52 PM, Alexander Korotkov wrote: > >* I just noticed that the dummy trueTriConsistentFn returns GIN_MAYBE, >rather than GIN_TRUE. The equivalent boolean version returns 'true' without >recheck. Is that a typo, or was there some reason for the discrepancy? > Actually, there is no

[HACKERS] JSON Patch (RFC 6902) support?

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? https://tools.ietf.org/html/rfc6902 One of the problems I have as a user is how to update a portion of a

[HACKERS] Proposal to join the hackers list

Hi, We are computer engineering students from Maharashtra Institute of Technology, Pune, Maharashtra, India. We are pursuing Bachelor of Engineering degree in Computer Engineering. As a part of the curriculum, we are supposed to perform a group project in the final year on a topic of our choice.

Re: [HACKERS] [PATCH] Store Extension Options

Andres Freund writes: > On 2014-03-13 11:26:10 -0400, Robert Haas wrote: >> I have however had the thought before that it would be nice to allow >> for callbacks of invalidation functions of some kind even on catalogs >> that don't have catcaches. > Unfortunately the format catcache invalidations

Re: [HACKERS] Postgresql XML parsing

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 th

Re: [HACKERS] Is this a bug

fabriziomello wrote > On Thu, Mar 13, 2014 at 10:34 AM, Euler Taveira < > euler@.com > > > wrote: >> >> On 13-03-2014 00:11, Fabrízio de Royes Mello wrote: >> > Shouldn't the "ALTER" statements below raise an exception? >> > >> For consistency, yes. Who cares? I mean, there is no harm in resettin

Re: [HACKERS] [PATCH] Store Extension Options

On 2014-03-13 11:26:10 -0400, Robert Haas wrote: > On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane wrote: > > If there's not a catcache for pg_seclabels, I'd have no objection > > to adding one. As for your "userland cache" objection, you certainly > > could build such a thing using the existing inval

Re: [HACKERS] [PATCH] Store Extension Options

On 2014-03-13 11:20:02 -0400, Robert Haas wrote: > At the same time, I > don't feel compelled to provide an autoload mechanism to cover the > case where a user tries to set a label in a session which does not > have the label provider preloaded. I don't think there's that much need for that to be

Re: [HACKERS] [PATCH] Store Extension Options

On 2014-03-13 11:15:56 -0400, Robert Haas wrote: > On Thu, Mar 13, 2014 at 10:27 AM, Andres Freund > wrote: > > On 2014-03-13 10:24:09 -0400, Tom Lane wrote: > >> Andres Freund writes: > >> > But security labels are a nice idea, will think about it. AFAICs there's > >> > no builtin subdivision w

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 11:11 AM, Tom Lane wrote: > Andres Freund writes: >> On 2014-03-13 10:26:11 -0400, Tom Lane wrote: >>> No, because relcache doesn't store security labels to start with. >>> There's a separate catalog cache for security labels, I believe, >>> and invalidating entries in tha

Re: [HACKERS] [PATCH] Store Extension Options

Robert Haas escribió: > Well, I don't have a big problem with the idea that some sessions > might not have a certain extension loaded. For some extensions, that > might not lead to very coherent behavior, but I guess it's the > extension developer's job to tell the user whether or not that > exte

Re: [HACKERS] pg_archivecleanup bug

On Thu, Mar 13, 2014 at 1:48 AM, Bruce Momjian wrote: > On Mon, Dec 9, 2013 at 11:27:28AM -0500, Robert Haas wrote: >> On Thu, Dec 5, 2013 at 6:15 PM, Tom Lane wrote: >> > But the other usages seem to be in assorted utilities, which >> > will need to do it right for themselves. initdb.c's walkd

Re: [HACKERS] Postgresql XML parsing

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 the output PostgreSQL produces (hard coding the

Re: [HACKERS] [PATCH] Store Extension Options

On 2014-03-13 11:11:51 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-03-13 10:26:11 -0400, Tom Lane wrote: > >> No, because relcache doesn't store security labels to start with. > >> There's a separate catalog cache for security labels, I believe, > >> and invalidating entries in that

Re: [HACKERS] jsonb and nested hstore

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 lik

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 10:45 AM, Andres Freund wrote: > On 2014-03-13 10:31:12 -0400, Robert Haas wrote: >> I think the really interesting question >> here is how the dump-and-reload issue ought to be handled. As Tom >> says, it seems on the surface as though you can either require that >> the p

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 10:27 AM, Andres Freund wrote: > On 2014-03-13 10:24:09 -0400, Tom Lane wrote: >> Andres Freund writes: >> > But security labels are a nice idea, will think about it. AFAICs there's >> > no builtin subdivision within the label for one provider which is a bit >> > of a sham

Re: [HACKERS] [PATCH] Store Extension Options

Andres Freund writes: > On 2014-03-13 10:26:11 -0400, Tom Lane wrote: >> No, because relcache doesn't store security labels to start with. >> There's a separate catalog cache for security labels, I believe, >> and invalidating entries in that ought to be sufficient. > There doesn't seem to be any

Re: [HACKERS] jsonb and nested hstore

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. (Tangentially, I wonder if it wouldn't be possible to make this a plain cast. I'm not sure but

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

In this loop, > + for (i = 0; i < desc->natts; i++) > + { > + char *val; > + int vallen; > + > + vallen = strlen(val); > +

Re: [HACKERS] [PATCH] Store Extension Options

On 2014-03-13 10:31:12 -0400, Robert Haas wrote: > I think the really interesting question > here is how the dump-and-reload issue ought to be handled. As Tom > says, it seems on the surface as though you can either require that > the provider be loaded for that, or you can accept unvalidated > se

Re: [HACKERS] [PATCH] Store Extension Options

On 13 March 2014 14:36, Simon Riggs wrote: > I like that suggestion, all of it. > > Perhaps change it to METADATA LABEL ? Damn. It works, apart from the fact that we don't get parameter=value. That may not be critical, since most use cases I can think of are booleans. -- Simon Riggs

Re: [HACKERS] [PATCH] Store Extension Options

On 2014-03-13 10:26:11 -0400, Tom Lane wrote: > [ forgot to respond to this part ] > > Andres Freund writes: > > They currently don't seem to create invalidations on the objects they > > are set upon, maybe we should change that? > > No, because relcache doesn't store security labels to start wi

Re: [HACKERS] [PATCH] Store Extension Options

Robert Haas escribió: > Basically, my feeling is that if you install an extension that adds > new table-level options, that's effectively a new version of the > database, and expecting a dump from that version to restore into a > vanilla database is about as reasonable as expecting 9.4 dumps to >

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 10:22 AM, Simon Riggs wrote: > On 13 March 2014 13:17, Robert Haas wrote: > >> The bottom line here is that, as in previous years, there are a >> certain number of people who show up near the end of CF4 and are >> unhappy that some patch didn't get committed. Generally, t

Re: [HACKERS] [PATCH] Store Extension Options

On 13 March 2014 14:03, Robert Haas wrote: > On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund wrote: >> On 2014-03-13 09:17:36 -0400, Robert Haas wrote: >>> It is very true that there are other ways for extensions to manage >>> per-table options. >> >> You previously said that, but I really don't s

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

On Thu, Mar 13, 2014 at 7:10 PM, Robert Haas wrote: > On Thu, Mar 13, 2014 at 12:45 AM, Amit Kapila wrote: >> _bt_doinsert - "insert index tuple (X,Y)" (here it will refer to index tuple >> location) > > I don't think that giving the index tuple location is going to be very > helpful; can we get

Re: [HACKERS] [PATCH] Store Extension Options

Andres Freund writes: > But security labels are a nice idea, will think about it. AFAICs there's > no builtin subdivision within the label for one provider which is a bit > of a shame but solvable. The biggest issue I see is that it essentially > seems to require that the provider is in > {shared,

Re: [HACKERS] [PATCH] Store Extension Options

On 13 March 2014 13:17, Stephen Frost wrote: > In the end, perhaps we should just add another field which is called > 'custom_reloptions' and allow that to be the "wild west"? That makes sense. > ... and allow that to be the "wild west"? but that would be an emotive phrase that doesn't help ac

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 10:20 AM, Andres Freund wrote: >> Well, I'm not going to claim that the methods that exist today are >> perfect. Things you can do include: (1) the table of tables approach, >> (2) abusing comments, and perhaps (3) abusing the security label >> machinery. SECURITY LABEL F

Re: [HACKERS] [PATCH] Store Extension Options

On 2014-03-13 10:24:09 -0400, Tom Lane wrote: > Andres Freund writes: > > But security labels are a nice idea, will think about it. AFAICs there's > > no builtin subdivision within the label for one provider which is a bit > > of a shame but solvable. The biggest issue I see is that it essentially

Re: [HACKERS] [PATCH] Store Extension Options

[ forgot to respond to this part ] Andres Freund writes: > They currently don't seem to create invalidations on the objects they > are set upon, maybe we should change that? No, because relcache doesn't store security labels to start with. There's a separate catalog cache for security labels, I

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

Robert Haas writes: > Well, it's sounding like we can only display the whole tuple if (1) > the message level is less than ERROR and (2) the snapshot is an MVCC > snapshot. That's an annoying and hard-to-document set of limitations. > But we should be able to display the TID always, so I think w

Re: [HACKERS] [PATCH] Store Extension Options

On 13 March 2014 13:17, Robert Haas wrote: > The bottom line here is that, as in previous years, there are a > certain number of people who show up near the end of CF4 and are > unhappy that some patch didn't get committed. Generally, they allege > that (1) there's nothing wrong with the patch,

Re: [HACKERS] [PATCH] Store Extension Options

On 2014-03-13 10:03:03 -0400, Robert Haas wrote: > On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund wrote: > > On 2014-03-13 09:17:36 -0400, Robert Haas wrote: > >> It is very true that there are other ways for extensions to manage > >> per-table options. > > > > You previously said that, but I real

Re: [HACKERS] Is this a bug?

On Thu, Mar 13, 2014 at 10:34 AM, Euler Taveira wrote: > > On 13-03-2014 00:11, Fabrízio de Royes Mello wrote: > > Shouldn't the "ALTER" statements below raise an exception? > > > For consistency, yes. Who cares? I mean, there is no harm in resetting > an unrecognized parameter. Have in mind that

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 9:26 AM, Andres Freund wrote: > On 2014-03-13 09:17:36 -0400, Robert Haas wrote: >> It is very true that there are other ways for extensions to manage >> per-table options. > > You previously said that, but I really don't see any. Which way out > there exists that a) doesn'

Re: [HACKERS] gaussian distribution pgbench

On Thu, Mar 13, 2014 at 10:51 PM, Heikki Linnakangas wrote: > On 03/13/2014 03:17 PM, Fujii Masao wrote: >> >> On Tue, Mar 11, 2014 at 1:49 PM, KONDO Mitsumasa >> wrote: >>> >>> (2014/03/09 1:49), Fabien COELHO wrote: I'm okay with this UI and its implementation. >>> >>> >>> OK. >>

Re: [HACKERS] gaussian distribution pgbench

On 03/13/2014 03:17 PM, Fujii Masao wrote: On Tue, Mar 11, 2014 at 1:49 PM, KONDO Mitsumasa wrote: (2014/03/09 1:49), Fabien COELHO wrote: I'm okay with this UI and its implementation. OK. We should do the same discussion for the UI of command-line option? The patch adds two options --gau

Re: [HACKERS] jsonb and nested hstore

On Thu, Mar 13, 2014 at 1:08 PM, Andrew Dunstan wrote: > ->> returns dequoted text if the value it points to is a plain string. If > it's not doing that then that's a bug. Sorry, I must have gotten confused between various tests. It does seem to be doing that. -- greg -- Sent via pgsql-hack

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

On Thu, Mar 13, 2014 at 12:45 AM, Amit Kapila wrote: >> While attempting to "operate in"? That seems like unhelpful >> weasel-wording. I wonder if we ought to have separate messages for >> each possibility, like "delete tuple (X,Y)" when called from >> heap_delete(), "update tuple (X,Y)", "check

Re: [HACKERS] Is this a bug?

On 13-03-2014 00:11, Fabrízio de Royes Mello wrote: > Shouldn't the "ALTER" statements below raise an exception? > For consistency, yes. Who cares? I mean, there is no harm in resetting an unrecognized parameter. Have in mind that tighten it up could break scripts. In general, I'm in favor of vali

Re: [HACKERS] [PATCH] Store Extension Options

On 2014-03-13 09:17:36 -0400, Robert Haas wrote: > It is very true that there are other ways for extensions to manage > per-table options. You previously said that, but I really don't see any. Which way out there exists that a) doesn't leave garbage after the relation is dropped or renamed b) is p

Re: [HACKERS] Is this a bug?

On Wed, Mar 12, 2014 at 11:11 PM, Fabrízio de Royes Mello wrote: > Hi all, > > Shouldn't the "ALTER" statements below raise an exception? > > fabrizio=# CREATE TABLE foo(bar SERIAL PRIMARY KEY); > CREATE TABLE > > fabrizio=# SELECT relname, reloptions FROM pg_class WHERE relname ~ '^foo'; >rel

Re: [HACKERS] jsonb and nested hstore

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) Tha

Re: [HACKERS] [PATCH] Store Extension Options

On Thu, Mar 13, 2014 at 12:47 AM, Simon Riggs wrote: > On 13 March 2014 02:14, Robert Haas wrote: >>> I'm not sure why this is being blocked. This is a community >>> contribution that seeks to improve everybody's options. Blocking it >>> does *nothing* to prevent individual extensions from provid

Re: [HACKERS] gaussian distribution pgbench

On Tue, Mar 11, 2014 at 1:49 PM, KONDO Mitsumasa wrote: > (2014/03/09 1:49), Fabien COELHO wrote: >> >> >> Hello Mitsumasa-san, >> >>> New "\setrandom" interface is here. >>> \setrandom var min max [gaussian threshold | exponential threshold] >> >> >>> Attached patch realizes this interface, but

Re: [HACKERS] [PATCH] Store Extension Options

* Tom Lane (t...@sss.pgh.pa.us) wrote: > I don't really think partial validation makes sense. We could just remove > the whole topic, and tell extension authors that it's up to them to defend > themselves against bizarre values stored for their table options. But I'm > wondering if there's really

Re: [HACKERS] jsonb and nested hstore

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 repr

Re: [HACKERS] inherit support for foreign tables

Hi Horiguchi-san, Thank you for working this patch! (2014/03/10 17:29), Kyotaro HORIGUCHI wrote: Hello. As a minimal implementation, I made an attempt that emit NOTICE message when alter table affects foreign tables. It looks like following, | =# alter table passwd add column added int, add co

Re: [HACKERS] jsonb and nested hstore

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) It's still more than 7x faster in cpu costs though:

Re: [HACKERS] jsonb and nested hstore

On Thu, Mar 13, 2014 at 4:21 PM, Alexander Korotkov wrote: > On Thu, Mar 13, 2014 at 1:21 PM, Greg Stark wrote: >> >> Well these are just normal gin and gist indexes. If we want to come up >> with new index operator classess we can still do that and keep the old >> ones if necessary. Even that se

Re: [HACKERS] jsonb and nested hstore

On Thu, Mar 13, 2014 at 1:21 PM, Greg Stark wrote: > Well these are just normal gin and gist indexes. If we want to come up > with new index operator classess we can still do that and keep the old > ones if necessary. Even that seems pretty unlikely from past experience. > > I'm actually pretty s

Re: [HACKERS] 9a57858f1103b89a5674f0d50c5fe1f756411df6

On 2014-03-13 13:06:00 +0100, Jozef Mlich wrote: > Does this affect also other branches? 9.2 ? Nope, it's 9.3 only. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers

Re: [HACKERS] 9a57858f1103b89a5674f0d50c5fe1f756411df6

On Thu, 2014-03-13 at 12:00 +0100, Andres Freund wrote: > On 2014-03-12 20:09:23 -0400, Robert Haas wrote: > > On the pgsql-packagers list, there has been some (OT for that list) > > discussion of whether commit 9a57858f1103b89a5674f0d50c5fe1f756411df6 > > is sufficiently serious to justify yet ano

Re: [HACKERS] COPY table FROM STDIN doesn't show count tag

ommand tag will not be displayed. 2. In-case of \COPY ... TO ..., command tag will not be displayed. 3. In all other cases, command tag will be displayed similar as were getting displayed earlier. I have modified the corresponding documentation. Please find the attached revised patch. Thanks and

Re: [HACKERS] db_user_namespace a "temporary measure"

On 2014-03-12 20:54:36 -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Mar 12, 2014 at 9:19 AM, Andres Freund > > wrote: > >> Except that we don't have the infrastructure to perform such checks > >> (neither partial, nor expression indexes, no exclusion constraints) on > >> system table

Re: [HACKERS] Replication slots and footguns

On 2014-03-12 13:34:47 -0700, Josh Berkus wrote: > On 03/12/2014 12:34 PM, Robert Haas wrote: > >>> Urgh. That error message looks susceptible to improvement. How about: > >>> >> > >>> >> replication slot "%s" cannot be dropped because it is currently in use > >> > > >> > I think that'd require d

Re: [HACKERS] 9a57858f1103b89a5674f0d50c5fe1f756411df6

On 2014-03-12 20:09:23 -0400, Robert Haas wrote: > On the pgsql-packagers list, there has been some (OT for that list) > discussion of whether commit 9a57858f1103b89a5674f0d50c5fe1f756411df6 > is sufficiently serious to justify yet another immediate minor release > of 9.3.x. The relevant questions

Re: [HACKERS] jsonb and nested hstore

Fwiw I have a few questions -- but beware, I'm a complete neophyte when it comes to jsonb style document databases so these are more likely to represent misconceptions on my part than problems with jsonb. I naively though a gin index on a jsonb would help with queries like WHERE col->'prop' = 'val

Re: [HACKERS] jsonb and nested hstore

On Thu, Mar 13, 2014 at 6:15 AM, Bruce Momjian wrote: > On Wed, Mar 12, 2014 at 01:58:14PM -0700, Peter Geoghegan wrote: >> The use case you describe here doesn't sound like something similar to >> full text search. It sounds like something identical. >> >> In any case, let's focus on what we have