On 03/06/2014 04:33 AM, Robert Haas wrote:
> On Wed, Mar 5, 2014 at 8:54 PM, Bruce Momjian wrote:
>> On Mon, Nov 11, 2013 at 05:48:52PM +0100, Antonin Houska wrote:
>>> On 11/10/2013 12:57 AM, Robert Haas wrote:
On Thu, Nov 7, 2013 at 10:56 AM, Antonin Houska
wrote:
> catalog/catalo
2014-03-05 16:22 GMT+01:00 Alvaro Herrera :
> Pavel Stehule escribió:
> > Hi
> >
> > I hope, so this patch fix it
>
> wtf?
>
I tried to fix
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f1ba94bcd9717b94b36868d6905547e313f3a359
Tom did it better than me.
Regards
Pavel
>
>
On 03/05/2014 09:07 PM, Peter Geoghegan wrote:
> It's hard to justify having a user-facing hstore2 on the grounds of
> backwards compatibility, and giving those stuck on hstore the benefit
> of all of these new capabilities. That's because we *cannot* really
> preserve compatibility, AFAICT. Many o
On Wed, Mar 5, 2014 at 11:32 AM, Bruce Momjian wrote:
> So, now knowing that hstore2 is just hierarchical hstore using the same
> hstore type name, you are saying that we are keeping the
> non-hierarchical code in contrib, and the rest goes into core --- that
> makes sense, and from a code mainten
On Thu, Mar 6, 2014 at 4:38 AM, Bruce Momjian wrote:
> On Mon, Nov 4, 2013 at 11:31:30AM -0500, Robert Haas wrote:
>> On Sat, Nov 2, 2013 at 3:32 PM, Peter Eisentraut wrote:
>> > This doesn't seem right:
>> >
>> > $ pg_ctl -D /nowhere status
>> > pg_ctl: no server running
>> >
>> > It does exit
> Kouhei Kaigai writes:
> >> * Please drop the whole register_custom_provider/get_custom_provider
> API.
>
> > One thing I was worrying about is how copyObject() and nodeToString()
> > support set of function pointer tables around custom-scan node,
> > however, you suggested to change the assumpt
On Tue, Mar 04, 2014 at 07:10:27PM -0500, Bruce Momjian wrote:
> On Sat, Mar 1, 2014 at 01:35:45PM -0500, Noah Misch wrote:
> > Having that said, I can appreciate the value of tightening the socket mode
> > for
> > a bit of *extra* safety:
> >
> > --- a/src/test/regress/pg_regress.c
> > +++ b/sr
This version looks basically good. I have some cosmetic things to sweep up
before commit. One point is a bit more substantial:
On Tue, Feb 04, 2014 at 01:16:22PM +0100, Ronan Dunklau wrote:
> Le lundi 3 février 2014 23:28:45 Noah Misch a écrit :
> > On Sun, Feb 02, 2014 at 11:53:51AM +0100, Rona
On Wed, Mar 5, 2014 at 8:54 PM, Bruce Momjian wrote:
> On Mon, Nov 11, 2013 at 05:48:52PM +0100, Antonin Houska wrote:
>> On 11/10/2013 12:57 AM, Robert Haas wrote:
>> > On Thu, Nov 7, 2013 at 10:56 AM, Antonin Houska
>> > wrote:
>> >> catalog/catalog.c:GetNewRelFileNode() and its calls indicate
On Wed, Mar 5, 2014 at 12:55 PM, Alex Hunsaker wrote:
> On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera
> wrote:
>
>> Can I bug you into verifying what supported releases need this patch,
>> and to which does it backpatch cleanly? And if there's any to which it
>> doesn't, can I further bug you
On Mar5, 2014, at 18:27 , Dean Rasheed wrote:
> On 5 March 2014 14:35, Florian Pflug wrote:
>> When I added the EXPLAIN stuff, I initially simply reported the number
>> of times nodeWindowAgg has to restart the aggregation. The problem with
>> that approach is that not all restarts carry the same
On Mon, Mar 3, 2014 at 4:12 PM, Robert Haas wrote:
> Unfortunately, I don't believe that it's possible to do this easily
> today because of the way bucket splits are handled. I wrote about
> this previously here, with an idea for solving the problem:
We could just tackle this in the same incompl
On 03/06/2014 04:56 AM, Yeb Havinga wrote:
>>> It might be an idea to add the SELECT RLS clause for DML
>>> queries that contain a RETURNING clause.
>> That way lies madness: A DML statement that affects *a different set of
>> rows* depending on whether or not it has a RETURNING clause.
> If you st
On Mon, Nov 11, 2013 at 05:48:52PM +0100, Antonin Houska wrote:
> On 11/10/2013 12:57 AM, Robert Haas wrote:
> > On Thu, Nov 7, 2013 at 10:56 AM, Antonin Houska
> > wrote:
> >> catalog/catalog.c:GetNewRelFileNode() and its calls indicate that the
> >> following change makes sense:
> >>
> >>
> >> d
On Thu, Nov 7, 2013 at 11:46:24AM +0900, Michael Paquier wrote:
> On Thu, Nov 7, 2013 at 9:14 AM, Steve Crawford
> wrote:
> > Due to a variety of messages over time regarding perceived weirdness in
> > to_timestamp and to_date, this patch adds "(see notes)" in the description
> > column for to_da
On 2014-03-05 20:02:56 -0500, Robert Haas wrote:
> On Wed, Mar 5, 2014 at 6:50 PM, Andres Freund wrote:
> Urgh. I know that isn't per project style, but I just plain missed it
> while staring at these patches. At one point I thought of complaining
> that separating the public and private values
On 2014-03-05 20:03:16 -0500, Tom Lane wrote:
> However, this is probably a bit beside the point. I'm quite prepared
> to believe that nobody uses gcc < 4.0 anymore. The question is what
> older non-gcc compilers are still out there, and can we either get hold
> of them for the buildfarm, or trus
Andres Freund writes:
> On 2014-03-05 19:12:15 -0500, Tom Lane wrote:
>> I'm surprised too; I had thought we still had some critters running
>> hoary compilers. We need to do something about that if we actually
>> believe in C90-compiler support.
> What version was the gcc that triggered the err
On Wed, Mar 5, 2014 at 6:50 PM, Andres Freund wrote:
> On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
>> I don't believe that this is legal per C90:
>>
>> typedef struct ReorderBufferChange
>> {
>> XLogRecPtrlsn;
>>
>> /* type of change */
>> union
>> {
>> enum ReorderBu
On 2014-03-05 19:12:15 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
> >> By the time you get done fixing the portability issue, I suspect you
> >> won't have a union at all for the first case.
>
> > You might be right. I'd rather not leak the in
On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund
wrote:
> >
> > On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
> > > On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund
wrote:
> > > > On 2014-03-04 09:47:08 -
On Tue, Nov 5, 2013 at 08:36:32PM +0100, Andres Freund wrote:
> On 2013-11-04 13:48:32 +0100, Andres Freund wrote:
> > What about just unowning the smgr entry with
> > if (rel->rd_smgr != NULL)
> >smgrsetowner(NULL, rel->rd_smgr)
> > when closing the fake relcache entry?
> >
> > That shouldn'
Andres Freund writes:
> On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
>> By the time you get done fixing the portability issue, I suspect you
>> won't have a union at all for the first case.
> You might be right. I'd rather not leak the internal enum values to the
> public though, so there are tw
On 2014-03-05 17:40:56 -0500, Tom Lane wrote:
> I don't believe that this is legal per C90:
>
> typedef struct ReorderBufferChange
> {
> XLogRecPtrlsn;
>
> /* type of change */
> union
> {
> enum ReorderBufferChangeType action;
> /* do not leak internal enum va
On Wed, Nov 6, 2013 at 08:47:43AM -0500, Peter Eisentraut wrote:
> On 11/5/13, 8:46 AM, Pavel Golub wrote:
> > I suppose this should be call to exit_nicely() for all possible cases.
> >
> > The only need for calling exit_horribly() is when we are deep down in
> > the multithreaded code, AFAIK.
>
On Mon, Nov 4, 2013 at 11:31:30AM -0500, Robert Haas wrote:
> On Sat, Nov 2, 2013 at 3:32 PM, Peter Eisentraut wrote:
> > This doesn't seem right:
> >
> > $ pg_ctl -D /nowhere status
> > pg_ctl: no server running
> >
> > It does exit with status 3, so it's not all that broken, but I think the
> >
On Wed, Mar 5, 2014 at 4:24 PM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost wrote:
>> > I don't see why we can't do exactly what you're suggesting in core.
>>
>> Because you can't (if you're defining core to mean 'not an
>>
I don't believe that this is legal per C90:
typedef struct ReorderBufferChange
{
XLogRecPtrlsn;
/* type of change */
union
{
enum ReorderBufferChangeType action;
/* do not leak internal enum values to the outside */
intaction_internal;
}
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 2:46 PM, Stephen Frost wrote:
> > I don't see why we can't do exactly what you're suggesting in core.
>
> Because you can't (if you're defining core to mean 'not an
> extension'). Functions can't be removed or changed because
On 2014-03-05 17:05:24 -0500, Robert Haas wrote:
> > I very much dislike having the three different event loops, but it's
> > pretty much forced by the design of the xlogreader. "My" xlogreader
> > version didn't block when it neeeded to wait for WAL but just returned
> > "need input/output", but w
On Mar5, 2014, at 18:37 , Tom Lane wrote:
> Dean Rasheed writes:
>> I think we really need a larger consensus on this though, so I'd be
>> interested to hear what others think.
>
> My advice is to lose the EXPLAIN output entirely. If the authors of
> the patch can't agree on what it means, what
On Wed, Mar 5, 2014 at 12:32 PM, Rohit Goyal wrote:
> Hi All,
>
> Is there any ways by which i can disable the hot-update functionality?
>
Build an index on a volatile column. For example, to force pgbench to
bypass HOT updates for testing purposes I build an index on
pgbench_accounts (abalance
On Wed, Mar 5, 2014 at 2:45 PM, Alvaro Herrera wrote:
> Merlin Moncure escribió:
>> It doesn't magically fix it, but at least provides a way forward. If
>> the function you want to modify is in an extension 'foo', you get to
>> put your new stuff in 'foo2' extension. That way your users do not
>>
On Wed, Mar 5, 2014 at 3:04 PM, Andres Freund wrote:
> Hi,
>
> On 2014-03-05 13:49:23 -0500, Robert Haas wrote:
>> PLEASE stop using a comma to join two independent thoughts.
>
> Ok. I'll try.
>
> Is this a personal preference, or a general rule? There seems to be a
> fair amount of comments in pg
On 2014-03-05 18:26:13 +0200, Heikki Linnakangas wrote:
> On 02/25/2014 06:41 PM, Robert Haas wrote:
> >On Tue, Feb 25, 2014 at 11:23 AM, Andres Freund
> >wrote:
> >>Usually that state will be reached very quickly because before
> >>that we're writing data to the network as fast as it can be read
Merlin Moncure escribió:
> On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost wrote:
> > We have backwards compatibility "problems" because we don't want to
> > *break* things for people. Moving things into extensions doesn't
> > magically fix that- if you break something in a backwards-incompatible
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost wrote:
> > We have backwards compatibility "problems" because we don't want to
> > *break* things for people. Moving things into extensions doesn't
> > magically fix that- if you break something in a bac
On Wed, Mar 5, 2014 at 5:32 PM, Rohit Goyal wrote:
>
> Hi All,
>
> Is there any ways by which i can disable the hot-update functionality?
>
Why do you want do that?
Grettings,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http
On 2014-03-05 18:39:52 +0100, Andres Freund wrote:
> On March 5, 2014 6:07:43 PM CET, Tom Lane wrote:
> >$ pg_dump -F d -j 4 -f foo regression
> >pg_dump: [archiver (db)] query failed: pg_dump: [parallel archiver]
> >query was: SET TRANSACTION SNAPSHOT '2130-1'
> >pg_dump: [archiver (db)] quer
Hi All,
Is there any ways by which i can disable the hot-update functionality?
--
Regards,
Rohit Goyal
On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas wrote:
>
> Unfortunately, I don't believe that it's possible to do this easily
> today because of the way bucket splits are handled. I wrote about
> this previously here, with an idea for solving the problem:
>
>
> http://www.postgresql.org/message-id/
Hi,
On 2014-03-05 13:49:23 -0500, Robert Haas wrote:
> PLEASE stop using a comma to join two independent thoughts.
Ok. I'll try.
Is this a personal preference, or a general rule? There seems to be a
fair amount of comments in pg doing so?
> This patch still treats "allow a walsender to connect
On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost wrote:
>> > Yeah, from what I gather you're suggesting, that's more-or-less "move it
>> > all to core", except that all of the actual interface bi
On Wed, Mar 5, 2014 at 12:22 PM, Alvaro Herrera
wrote:
> Can I bug you into verifying what supported releases need this patch,
> and to which does it backpatch cleanly? And if there's any to which it
> doesn't, can I further bug you into providing one that does?
Sure! Not bugging at all. I'll d
On Wed, Mar 5, 2014 at 4:06 PM, Robert Haas wrote:
>
> On Tue, Mar 4, 2014 at 3:33 PM, Fabrízio de Royes Mello
> wrote:
> > Is the TODO item "CREATE SCHEMA ... LIKE ..." [1] a good GSoC project?
>
> Maybe. I'm not sure that everyone would agree that it's a good idea.
> And it'd probably involve
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
> On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas 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
Joel Jacobson wrote:
> Hi,
>
> I've tried to fix some bugs reported by Andrey Karpov in an article at
> http://www.viva64.com/en/b/0227/
>
> The value returned by socket() is unsigned on Windows and can thus not
> be checked if less than zero to detect an error, instead
> PGINVALID_SOCKET should
Kouhei Kaigai writes:
>> * Please drop the whole register_custom_provider/get_custom_provider API.
> One thing I was worrying about is how copyObject() and nodeToString() support
> set of function pointer tables around custom-scan node, however, you suggested
> to change the assumption here. So,
Alex Hunsaker escribió:
> On Tue, Feb 25, 2014 at 6:56 AM, Sergey Burladyan wrote:
>
> > It looks like I found the problem, Perl use reference count and something
> > that
> > is called "Mortal" for memory management. As I understand it, mortal is
> > free
> > after FREETMPS. Plperl call FREET
On Wed, Mar 5, 2014 at 5:13 PM, Amit Langote wrote:
> On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote wrote:
>> On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko
>> wrote:
>>
>>>
>>> xlog.c:6177
>>> if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
>>> ereport(ERROR,
>>> (errms
On 03/05/2014 11:05 AM, Bruce Momjian wrote:
> Can you clarify what hstore2 is? It that the name of a type? Is that
> hierarchical hstore with the same hstore name?
hstore2 == nested heirarchical hstore. It's just a shorthand; there
won't be any actual type called "hstore2", by design. Unlike
On Tue, Mar 4, 2014 at 3:33 PM, Fabrízio de Royes Mello
wrote:
> Is the TODO item "CREATE SCHEMA ... LIKE ..." [1] a good GSoC project?
Maybe. I'm not sure that everyone would agree that it's a good idea.
And it'd probably involve mucking with a bunch of tablecmds.c code
that is kind of a mess a
On Wed, Mar 5, 2014 at 10:59:37AM -0800, Peter Geoghegan wrote:
> On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas 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
On Wed, Mar 5, 2014 at 1:57 PM, Josh Berkus wrote:
> On 03/05/2014 10:49 AM, Robert Haas wrote:
>> This patch still treats "allow a walsender to connect to a database"
>> as a separate feature from "allow logical replication". I'm not
>> convinced that's a good idea. What you're proposing to do i
Kyotaro HORIGUCHI writes:
>> ec_relids has never included child relids.
> relation.h says that,
> |Relids ec_relids; /* all relids appearing in ec_members */
> ...
> |Relids em_relids; /* all relids appearing in em_expr */
Ah. Those comments could use improvement, I guess.
On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas 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 instead of argue about it?
>
>
Craig Ringer writes:
> One of the remaining issues with row security is how to pass plan
> invalidation information generated in the rewriter back into the planner.
> With row security, it's necessary to set a field in PlannerGlobal,
> tracking the user ID of the user the query was planned for if
On 03/05/2014 10:49 AM, Robert Haas wrote:
> This patch still treats "allow a walsender to connect to a database"
> as a separate feature from "allow logical replication". I'm not
> convinced that's a good idea. What you're proposing to do is allow
> replication=database in addition to replication
On Tue, Mar 4, 2014 at 6:26 PM, Andres Freund wrote:
> On 2014-03-03 16:48:15 -0500, Robert Haas wrote:
>> OK, I've committed the 0001 patch, which is the core of this feature,
>> with a bit of minor additional hacking.
>
> Attached are the rebased patches that are remaining.
>
> Changes:
> * mino
Tom,
I did not follow the thread very close, so I need to look what the
ambiguity is there, however I would love to see window rescans in explain
analyze.
I have great experience in tuning Oracle queries.
There are features in PostgreSQL's explain analyze that I miss badly in
Oracle: 'rows remove
On 03/05/2014 09:26 AM, Robert Haas wrote:
>> > What _would_ be interesting is to move all the hstore code into core,
>> > and have hstore contrib just call the hstore core parts. That way, you
>> > have one copy of the code, it is shared with JSONB, but hstore remains
>> > as an extension that yo
On Wed, Mar 5, 2014 at 12:57 PM, Erik Rijkers wrote:
> Four files with comment typos.
Committed, thanks. For future reference, a single patch is easier
than four separate ones.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hacke
Four files with comment typos.
--- src/backend/replication/logical/decode.c.orig 2014-03-05 18:44:31.725317514 +0100
+++ src/backend/replication/logical/decode.c 2014-03-05 18:45:09.577190828 +0100
@@ -497,7 +497,7 @@
/*
* Check whether we are interested in this specific transaction, an
On Wed, Mar 5, 2014 at 11:19 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
>>> While there's certainly much to be said for the idea that jsonb should be
>>> an extension, I don't think we have the technology to package it as a
>>> *separate* ext
Craig Ringer escribió:
> One of the remaining issues with row security is how to pass plan
> invalidation information generated in the rewriter back into the planner.
I think I already asked this, but would it work to extract this info by
walking the rewritten list of queries instead; and in case
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost wrote:
> > Yeah, from what I gather you're suggesting, that's more-or-less "move it
> > all to core", except that all of the actual interface bits end up in an
> > extension that has to be installed to us
On March 5, 2014 6:07:43 PM CET, Tom Lane wrote:
>$ pg_dump -F d -j 4 -f foo regression
>pg_dump: [archiver (db)] query failed: pg_dump: [parallel archiver]
>query was: SET TRANSACTION SNAPSHOT '2130-1'
>pg_dump: [archiver (db)] query failed: pg_dump: [archiver (db)] query
>failed: pg_dump: [a
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. I
Dean Rasheed writes:
> I think we really need a larger consensus on this though, so I'd be
> interested to hear what others think.
My advice is to lose the EXPLAIN output entirely. If the authors of
the patch can't agree on what it means, what hope have everyday users
got of making sense of it?
On Wed, Mar 5, 2014 at 12:26:13PM -0500, Robert Haas wrote:
> >> It's not clear how much different it would be if we waited til 9.5
> >> either- do we anticipate a lot of code changes beyond the copy/paste for
> >> these?
> >
> > What _would_ be interesting is to move all the hstore code into core
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian wrote:
> > What _would_ be interesting is to move all the hstore code into core,
> > and have hstore contrib just call the hstore core parts. That way, you
> > have one copy of the code, it is shared wit
On 5 March 2014 14:35, Florian Pflug wrote:
> On Mar4, 2014, at 21:09 , Dean Rasheed wrote:
>> On 3 March 2014 23:00, Florian Pflug wrote:
* In show_windowagg_info(), this calculation looks suspicious to me:
double tperrow = winaggstate->aggfwdtrans /
(inst->n
On Wed, Mar 5, 2014 at 11:50 AM, Bruce Momjian wrote:
> On Wed, Mar 5, 2014 at 11:34:10AM -0500, 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 ta
Merlin Moncure writes:
> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
>> While there's certainly much to be said for the idea that jsonb should be
>> an extension, I don't think we have the technology to package it as a
>> *separate* extension; it'd have to be included in the hstore extension
On 2014-03-05 12:07:43 -0500, Tom Lane wrote:
> $ pg_dump -F d -j 4 -f foo regression
> pg_dump: [archiver (db)] query failed: pg_dump: [parallel archiver] query
> was: SET TRANSACTION SNAPSHOT '2130-1'
> pg_dump: [archiver (db)] query failed: pg_dump: [archiver (db)] query failed:
> pg_dump:
$ pg_dump -F d -j 4 -f foo regression
pg_dump: [archiver (db)] query failed: pg_dump: [parallel archiver] query was:
SET TRANSACTION SNAPSHOT '2130-1'
pg_dump: [archiver (db)] query failed: pg_dump: [archiver (db)] query failed:
pg_dump: [archiver (db)] query failed: $
postmaster log shows:
On Mar 5, 2014, at 8:49 AM, Andrew Dunstan wrote:
> I think that was my estimate, but Peter did offer to do it. He certainly
> asserted that the effort required would not be great. I'm all for taking up
> his offer.
+1 to this. Can you and Peter collaborate somehow to get it knocked out?
> In
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. I am suggesting that
> >core/contrib spli
On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
>> > Merlin Moncure writes:
>> *All* non-sql standard types ought to be in extensions in an ideal
>> world.
>> >
>> > While there's
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 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. That should all
On Wed, Mar 5, 2014 at 11:11:51AM -0500, Robert Haas wrote:
> An excellent question. This thread has become mostly about whether
> someone (like, say, me, or in this case Peter) is attempting to pull
> the rug out from under a previously-agreed consensus path forward.
> But despite my asking, nob
On Wed, Mar 5, 2014 at 11:34:10AM -0500, 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 d
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 instead
On Wed, Mar 5, 2014 at 11:16:01AM -0500, Tom Lane wrote:
> Bruce Momjian 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. That should allow user hstore columns to automatica
* Merlin Moncure (mmonc...@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
> > Merlin Moncure writes:
> *All* non-sql standard types ought to be in extensions in an ideal world.
> >
> > While there's certainly much to be said for the idea that jsonb should be
> > an exte
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane wrote:
> Merlin Moncure writes:
*All* non-sql standard types ought to be in extensions in an ideal world.
>
> While there's certainly much to be said for the idea that jsonb should be
> an extension, I don't think we have the technology to package it
* 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 instead of argue about it?
Somewhere upthread,
On Wed, Mar 5, 2014 at 11:24 AM, Tom Lane wrote:
> Merlin Moncure writes:
*All* non-sql standard types ought to be in extensions in an ideal world.
>
> While there's certainly much to be said for the idea that jsonb should be
> an extension, I don't think we have the technology to package it
On Wed, Mar 5, 2014 at 11:07 AM, Tom Lane wrote:
> Robert Haas writes:
>> And despite the assertions from various people here that these
>> decisions were all made a long time ago and it's way too late to
>> question them, I don't buy it. There's not a single email on this
>> mailing list clearl
On 02/25/2014 06:41 PM, Robert Haas wrote:
On Tue, Feb 25, 2014 at 11:23 AM, Andres Freund wrote:
Usually that state will be reached very quickly because before
that we're writing data to the network as fast as it can be read from
disk.
I'm unimpressed. Even if that is in practice true, maki
* Merlin Moncure (mmonc...@gmail.com) wrote:
> *All* non-sql standard types ought to be in extensions in an ideal world.
While I appreciate that you'd like to see it that way, others don't
agree (I certainly don't), and that ship sailed quite a long time ago
regardless. I'm not advocating putting
On Wed, Mar 5, 2014 at 10:19 AM, Andres Freund wrote:
> There's the absolutely significant issue that you cannot reasonably
> write extensions that interact on a C level. You can't call from
> extension to extension directly, but you can from extension to pg core
> provided ones.
Certainly. Note
Merlin Moncure writes:
>>> *All* non-sql standard types ought to be in extensions in an ideal world.
While there's certainly much to be said for the idea that jsonb should be
an extension, I don't think we have the technology to package it as a
*separate* extension; it'd have to be included in th
On 2014-03-05 10:10:23 -0600, Merlin Moncure wrote:
> On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian wrote:
> > On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
> >> *All* non-sql standard types ought to be in extensions in an ideal world.
> >
> > I have seen your opinion on this but
Bruce Momjian 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. That should allow user hstore columns to automatically map
> to the new constant hstore oid. We can also modify pg_u
On Mon, Mar 3, 2014 at 11:20 PM, Peter Geoghegan wrote:
> On Mon, Mar 3, 2014 at 6:59 PM, Josh Berkus 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 collecti
On Wed, Mar 5, 2014 at 9:52 AM, Bruce Momjian wrote:
> On Wed, Mar 5, 2014 at 09:19:33AM -0600, Merlin Moncure wrote:
>> On Wed, Mar 5, 2014 at 8: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.
>>
>> This is exactly th
On Wed, Mar 5, 2014 at 10:39:56AM -0500, Andrew Dunstan wrote:
>
> On 03/05/2014 10:30 AM, Tom Lane wrote:
> >Merlin Moncure writes:
> >>On Wed, Mar 5, 2014 at 9:24 AM, Tom Lane wrote:
> >>>Also, there might be other cases besides arrays where we've embedded
> >>>type OIDs in on-disk data; anyo
Robert Haas writes:
> And despite the assertions from various people here that these
> decisions were all made a long time ago and it's way too late to
> question them, I don't buy it. There's not a single email on this
> mailing list clearly laying out the design that we've ended up with,
> and
Tomas Vondra wrote:
> On 22.2.2014 01:13, Thom Brown wrote:
> > I've noticed that files for dropped databases aren't removed from
> > pg_stat_tmp. After a cluster-wide VACUUM ANALYSE, and restarting
> > Postgres, all the old database pg_stat_tmp files remain.
> Yeah, that's a bug in pgstat_recv_
1 - 100 of 127 matches
Mail list logo
