What happened to our work to add a JSON data type for PG 9.1?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On Thu, Jan 20, 2011 at 3:34 PM, Tom Lane wrote:
> Daniel Farina writes:
>> I wanted to test the waters on how receptive people might be to an
>> extension that would allow Postgres to support two passwords for a
>> given role.
>
> Not very. Why don't you just put two roles in the same group?
H
On Fri, 2011-01-21 at 00:26 +0100, Florian Pflug wrote:
> On Jan21, 2011, at 00:11 , Simon Riggs wrote:
> > It's not clear to me what the reason is that this doesn't just work on
> > HS already. If you started there it might help.
>
>
> The problem is that snapshots taken on the master sometimes
Tom Lane wrote:
> I'm pretty concerned about the performance implications, too. In
> particular that sounds like you could get an unbounded amount of
> WAL emitted from a *purely read only* transaction flow.
No. Read only transactions wouldn't create any flow at all. And I
suggested that we
> How does this work with newly created objects? Is there a way to have
> them default objects to a different owner, the parent of the two
> roles?
No, but you could easily assign default permissions.
> In the case of password rotation, the goal would be to
> drop the old password after all clie
On Thu, Jan 20, 2011 at 4:35 PM, Josh Berkus wrote:
>
>> How does this work with newly created objects? Is there a way to have
>> them default objects to a different owner, the parent of the two
>> roles?
>
> No, but you could easily assign default permissions.
>
>> In the case of password rotatio
On Fri, Jan 21, 2011 at 09:11, Bruce Momjian wrote:
> What happened to our work to add a JSON data type for PG 9.1?
Nothing will happen in 9.1.
I assume we are in "competition" status:
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00481.php
Also, if PGXN will work well, we might not h
Itagaki Takahiro wrote:
> On Fri, Jan 21, 2011 at 09:11, Bruce Momjian wrote:
> > What happened to our work to add a JSON data type for PG 9.1?
>
> Nothing will happen in 9.1.
> I assume we are in "competition" status:
>
> http://archives.postgresql.org/pgsql-hackers/2010-11/msg00481.php
>
> Al
> What I'm still not clear on is why that HS is different. Whatever rules
> apply on the master must also apply on the standby, immutably. Why is it
> we need to pass explicit snapshot information from master to standby? We
> don't do that, except at startup for normal HS. Why do we need that?
>
>
On Jan21, 2011, at 01:28 , Simon Riggs wrote:
> What I'm still not clear on is why that HS is different. Whatever rules
> apply on the master must also apply on the standby, immutably. Why is it
> we need to pass explicit snapshot information from master to standby? We
> don't do that, except at st
> * Eventual Retirement of old credentials without having to issue ALTER
> statements (or really statements of any kind...) against application
> schema objects.
OK, that's a different goal. You want to be able to expire passwords
with an overlap period. That's quite different from wanting an
i
Tom Lane wrote:
> Simon Riggs writes:
>> On Wed, 2011-01-19 at 19:05 -0600, Kevin Grittner wrote:
>>> The idea is that whenever we see a valid snapshot which would
>>> yield a truly serializable view of the data for a READ ONLY
>>> transaction, we add a WAL record with that snapshot information.
On Thu, Jan 20, 2011 at 5:32 PM, Josh Berkus wrote:
>
>> * Eventual Retirement of old credentials without having to issue ALTER
>> statements (or really statements of any kind...) against application
>> schema objects.
>
> OK, that's a different goal. You want to be able to expire passwords
> wit
* Daniel Farina (drfar...@acm.org) wrote:
> I have thought about that, although LDAP is the only one that came to
> mind (I don't know a whole lot of systems in detail, only by name...so
> suggestions welcome for low-administrative-overhead variants).
My preference is Kerberos and I find that it w
On Thu, Jan 20, 2011 at 8:32 PM, Josh Berkus wrote:
>
>> * Eventual Retirement of old credentials without having to issue ALTER
>> statements (or really statements of any kind...) against application
>> schema objects.
>
> OK, that's a different goal. You want to be able to expire passwords
> wit
On Thu, Jan 20, 2011 at 3:57 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I think filtered is pretty clear and like it...
>
> I find it ambiguous. [Takes sip of filtered water.]
Oh, you mean water that had some things you didn't want taken out of it?
--
Robert Haas
EnterpriseDB: http:/
* Robert Haas (robertmh...@gmail.com) wrote:
> It strikes me that it would be useful to have a GUC that sets the
> owner of any new objects you create (much as you can control their
> default schemas using search_path).
There was a great deal of discussion along these lines over the summer
of '09
On Thu, Jan 20, 2011 at 4:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 20, 2011 at 3:47 PM, Tom Lane wrote:
>>> BTW, is it just me, or is the terminology "number filtered" pretty
>>> confusing/ambiguous in itself? It doesn't seem at all clear to me
>>> whether that's the number o
On Thu, Jan 20, 2011 at 9:07 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> It strikes me that it would be useful to have a GUC that sets the
>> owner of any new objects you create (much as you can control their
>> default schemas using search_path).
>
> There was a gre
On Thu, Jan 20, 2011 at 6:12 PM, Robert Haas wrote:
> On Thu, Jan 20, 2011 at 9:07 PM, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> It strikes me that it would be useful to have a GUC that sets the
>>> owner of any new objects you create (much as you can control their
On Jan21, 2011, at 03:03 , Robert Haas wrote:
> It strikes me that it would be useful to have a GUC that sets the
> owner of any new objects you create (much as you can control their
> default schemas using search_path). Obviously, you'd need to restrict
> it so that it wouldn't allow you to creat
On Thu, Jan 20, 2011 at 4:40 PM, Simone Aiken
wrote:
> After playing with this in benchmarks and researching the weird results I
> got I'm going to advise dropping the todo for now unless something happens
> to change how postgres handles clustering.
I agree, let's remove it.
That having been sa
On Jan21, 2011, at 03:14 , Daniel Farina wrote:
> On Thu, Jan 20, 2011 at 6:12 PM, Robert Haas wrote:
>> On Thu, Jan 20, 2011 at 9:07 PM, Stephen Frost wrote:
>>> * Robert Haas (robertmh...@gmail.com) wrote:
It strikes me that it would be useful to have a GUC that sets the
owner of any
> Robert Haas wrote:
> On Thu, Jan 20, 2011 at 3:57 PM, Kevin Grittner
> wrote:
>> Robert Haas wrote:
>>
>>> I think filtered is pretty clear and like it...
>>
>> I find it ambiguous. [Takes sip of filtered water.]
>
> Oh, you mean water that had some things you didn't want taken out
> of it?
* Daniel Farina (drfar...@acm.org) wrote:
> On Thu, Jan 20, 2011 at 6:12 PM, Robert Haas wrote:
> > I'm not likely to write a patch for it, but if someone else writes one
> > I would be willing to (a) support it and (b) subject to consensus,
> > commit it.
>
> Wouldn't this require a client appli
On Thu, Jan 20, 2011 at 9:17 PM, Kevin Grittner
wrote:
> Right -- God only knows the number of things were filtered out to
> leave me with filtered water. What's "filtered" in this case is what
> was passed through, not what was removed.
Hmm, I guess I see your point now. Well, I'm not wedded t
"Kevin Grittner" writes:
>> Robert Haas wrote:
>> Oh, you mean water that had some things you didn't want taken out
>> of it?
> Right -- God only knows the number of things were filtered out to
> leave me with filtered water. What's "filtered" in this case is what
> was passed through, not wha
On Thu, Jan 20, 2011 at 8:54 PM, Kevin Grittner
wrote:
> As I mentioned in another email, we might want to throttle this. My
> thinking was that we could start a timer on capturing a snapshot, and
> continue to gather new ones as they become available. When you hit
> the timer limit (maybe 100ms
On 21/01/11 15:24, Robert Haas wrote:
On Thu, Jan 20, 2011 at 9:17 PM, Kevin Grittner
wrote:
Right -- God only knows the number of things were filtered out to
leave me with filtered water. What's "filtered" in this case is what
was passed through, not what was removed.
Hmm, I guess I see you
On Thu, Jan 20, 2011 at 11:17 AM, Simon Riggs wrote:
> On Wed, 2011-01-19 at 22:16 -0500, Robert Haas wrote:
>
>> That's another way of saying "the patch is not anywhere close to being done".
>
> My patch is materially incomplete. Certainly we may see that as grounds
> for rejection, which I would
On Thu, Jan 20, 2011 at 6:19 PM, Noah Misch wrote:
> On Thu, Jan 20, 2011 at 09:36:11PM +, Simon Riggs wrote:
>> I agree that the DDL behaviour is wrong and should be fixed. Thank you
>> for championing that alternative view.
>>
>> Swapping based upon names only works and is very flexible, muc
On Thu, Jan 20, 2011 at 9:35 PM, Mark Kirkwood
wrote:
> On 21/01/11 15:24, Robert Haas wrote:
>>
>> On Thu, Jan 20, 2011 at 9:17 PM, Kevin Grittner
>> wrote:
>>>
>>> Right -- God only knows the number of things were filtered out to
>>> leave me with filtered water. What's "filtered" in this cas
On Thu, Jan 20, 2011 at 10:17 AM, XiaoboGu wrote:
> Hi,
> We are using R to work with 64bit PostgreSQL client libraries, and
> to avoid compiler compatibility issues the R development community suggest
> using the same compiler for both the main application and dlls. So do you
> have any ex
On 01/20/2011 09:52 PM, Robert Haas wrote:
On Thu, Jan 20, 2011 at 10:17 AM, XiaoboGu wrote:
Hi,
We are using R to work with 64bit PostgreSQL client libraries, and
to avoid compiler compatibility issues the R development community suggest
using the same compiler for both the main appl
On Thu, Jan 20, 2011 at 2:22 PM, Noah Misch wrote:
> Okay. I've attached a new patch version based on that strategy.
Thanks. Committed and back-patched to 9.0 (but I didn't use your
regression test).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
-
On Mon, Jan 10, 2011 at 11:27 AM, Kevin Grittner
wrote:
> Attached is a rebased roll-up of the 3 and 3a patches from last month.
Sorry to be a dweeb, but do you have a link to previous discussion?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Se
On Sun, Jan 16, 2011 at 6:58 PM, Jeff Janes wrote:
> I found the following message somewhat confusing:
> ERROR: read-only property must be set before any query
I think what we need here is two messages, this one and a similar one
that starts with "read-write property...".
> When a subtransactio
On Fri, Jan 14, 2011 at 1:51 PM, Robert Haas wrote:
> On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs wrote:
>> This whole thing is confused. No change is appropriate here at all.
>>
>> We issue ERRCODE_T_R_SERIALIZATION_FAILURE almost all of the time for
>> recovery conflicts.
>>
>> We issue ERRCO
Robert Haas wrote:
> Kevin Grittner wrote:
>> Attached is a rebased roll-up of the 3 and 3a patches from last
>> month.
> do you have a link to previous discussion?
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00582.php
That thread seems to break, but if you look at the reference
> Robert Haas wrote:
> Jeff Janes wrote:
>> I found the following message somewhat confusing:
>> ERROR: read-only property must be set before any query
>
> I think what we need here is two messages, this one and a similar one
> that starts with "read-write property...".
>
>> When a subtransacti
On Thu, Jan 20, 2011 at 9:53 PM, Bernd Helmle wrote:
> I had a look at this for the current CF and the patch looks reasonable to
> me. Some testing shows that the changes are working as intended (at least,
> the wal sender actually receives now signals from SignalSomeChildren() as
> far as the DEB
> On Fri, Jan 14, 2011 at 1:51 PM, Robert Haas wrote:
>> On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs wrote:
>>> This whole thing is confused. No change is appropriate here at all.
>>>
>>> We issue ERRCODE_T_R_SERIALIZATION_FAILURE almost all of the time for
>>> recovery conflicts.
>>>
>>> We is
> Here is the patch to implement the feature.
>
> 1) pg_terminate_backend() sends SIGUSR1 signal rather than SIGTERM to
>the target backend.
> 2) The infrastructure used for message passing is
>storage/ipc/procsignal.c The new message type for ProcSignalReason
>is "PROCSIG_TERMNINATE_B
Robert Haas wrote:
> Kevin Grittner wrote:
>> As I mentioned in another email, we might want to throttle this.
>> My thinking was that we could start a timer on capturing a
>> snapshot, and continue to gather new ones as they become
>> available. When you hit the timer limit (maybe 100ms?) you se
On 1/20/2011 7:35 AM, Tom Lane wrote:
Marko Tiikkaja writes:
This seems useful, since the xact lock would be automatically released
if an error happens during "-- do something here" so you wouldn't need
to worry about releasing the lock elsewhere. But I'm not sure this is
safe. Can anyone see
On Fri, Jan 21, 2011 at 1:00 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Thu, Jan 20, 2011 at 10:53 AM, Tom Lane wrote:
I'm not sure why that's the right solution. Why do you think that we should
not create the tablespace under the $PGDATA directory? I'm not surprised
that peo
On 21.01.2011 03:19, Dan Ports wrote:
What I'm still not clear on is why that HS is different. Whatever rules
apply on the master must also apply on the standby, immutably. Why is it
we need to pass explicit snapshot information from master to standby? We
don't do that, except at startup for norm
On Fri, Jan 21, 2011 at 08:44:59AM +0200, Heikki Linnakangas wrote:
> We have enough information in the standby to reconstruct all writes done
> in the master. I gather that's not enough, in order to roll back
> read-only transaction T3 on the standby which would see an anomaly, we'd
> also need
101 - 148 of 148 matches
Mail list logo