On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote:
> I know it is late in the cycle
No problem here. Thanks for your diligence. Will review.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On Fri, Feb 12, 2010 at 9:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 12, 2010 at 8:06 PM, Tom Lane wrote:
>>> We could possibly put in some hack to disallow OLD/NEW references in
>>> the WITH queries, but that got past my threshold of ugliness, so
>>> I'm not going to commit it
We're down to 5 patches remaining, and 1 day remaining, so it's time
to try to wrap things up.
* Fix large object support in pg_dump. I think this is just waiting
for a second opinion on whether the approach is correct. I've been
meaning to look at it, but haven't gotten enough round tuits; mayb
Robert Haas writes:
> ...
> 2. Modify pg_amop by adding a new column amopcategory, probably either
> int2 or maybe even just char.
> ...
> I'm not prepared to endorse doing #3 in core for 9.0, but I wonder if
> it would be feasible to think about doing #1 and #2 and putting
> something into contri
On Sat, Feb 13, 2010 at 10:15 PM, Bruce Momjian wrote:
> Boszormenyi Zoltan wrote:
>> >>> Ah, I didn't even see that that section needed to be updated. Good
>> >>> catch. I'd suggest the following wording:
>> >>>
>> >>> For a SELECT or CREATE TABLE AS
>> >>> command, the tag is SELECT rows... [a
On Sat, Feb 13, 2010 at 3:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> Just to be clear, I was intending this patch, at least, to be applied
>> now. I actually think there's a good argument that we should do at
>> least this much for 9.0, namely that now is probably the time when
>> there are
Boszormenyi Zoltan wrote:
> >>> Ah, I didn't even see that that section needed to be updated. Good
> >>> catch. I'd suggest the following wording:
> >>>
> >>> For a SELECT or CREATE TABLE AS
> >>> command, the tag is SELECT rows... [and the rest as you have it]
> >>>
> >>> We should probably also
On Sat, Feb 13, 2010 at 3:34 AM, Greg Smith wrote:
> Robert Haas wrote:
>> Recording some bookkeeping information in pg_class so that pg_migrator can
>> tell what's going on
>> at a glance seems like the right approach, but I'm fuzzy on the details.
>
> November of 2008 was a pretty good month for
Hi *,
I just wanted all interested people know that psycopg2 2.0.14 to be
released in the next few days will be under the LGPL3 + OpenSSL
exception (example code and tests under the LGPL3 alone because they are
never linked to OpenSSL).
The Zope 2 and 3 adapters will be splitted out into their ow
David E. Wheeler wrote:
On Feb 13, 2010, at 3:35 PM, Andrew Dunstan wrote:
To perform initialisation, such as setting a value in %_SHARED.
Hrm. Well, as a DBA, I'd *really* like to be able to make some things available
from within a Safe container, such as Devel::NYTProf::PgPLPerl
"David E. Wheeler" writes:
> I'm not sure that Tim's interface is the best approach to giving DBAs
> the ability to do this from within PostgreSQL, but I'm hard-pressed to
> come up with a better interface. But I do think it should be allowed.
I think the fact that security worries have been rais
On Sat, 2010-02-13 at 13:28 -0500, Tom Lane wrote:
> If we didn't already have the plus/minus-for-WINDOW-RANGE example
> staring us in the face, I might think that an extensible solution
> wasn't needed here ... but we do so I think we really need to allow
> for multiple categories in some form.
I
On Feb 13, 2010, at 3:35 PM, Andrew Dunstan wrote:
> To perform initialisation, such as setting a value in %_SHARED.
Hrm. Well, as a DBA, I'd *really* like to be able to make some things available
from within a Safe container, such as Devel::NYTProf::PgPLPerl or the
PostgreSQL::PLPerl::Call mod
David E. Wheeler wrote:
On Feb 13, 2010, at 2:46 PM, Andrew Dunstan wrote:
I'm confused. Doesn't on_plperl_init already give us this? Isn't any of the stuff loaded by that GUC then available from inside the PLPerl Safe compartment?
No (and if it does it's a bug). Try it and see.
On Feb 13, 2010, at 2:46 PM, Andrew Dunstan wrote:
>> I'm confused. Doesn't on_plperl_init already give us this? Isn't any of the
>> stuff loaded by that GUC then available from inside the PLPerl Safe
>> compartment?
>
> No (and if it does it's a bug). Try it and see.
Then what's the point of
David E. Wheeler wrote:
On Feb 13, 2010, at 6:32 AM, Andrew Dunstan wrote:
My feeling is if we provide something we are responsible for it, documented or
not. Undocumented features with security implications raise big red flags in my
head. Maybe the difference in perspective comes from w
I have updated the attached C comment about why we return "0 0" for some
tags.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/tcop/pquery.c
On Feb 13, 2010, at 6:32 AM, Andrew Dunstan wrote:
> My feeling is if we provide something we are responsible for it, documented
> or not. Undocumented features with security implications raise big red flags
> in my head. Maybe the difference in perspective comes from working on a
> database as
On Feb 12, 2010, at 3:10 PM, Tim Bunce wrote:
> I've appended the POD documentation and attached the (rough but working)
> test script.
>
> I plan to release the module to CPAN in the next week or so.
>
> I'd greatly appreciate any feedback.
I like the idea overall, and anything that can simpli
Hi all,
I know it is late in the cycle, but I still think that the current behaviour
of ERRORing during execution of a query but FATALing during IDLE IN
TRANSACTION is very confusing to the user. Especially as you are not even able
to read the reason for getting disconnected because the client
Tom Lane writes:
> Teodor Sigaev writes:
>> I see your point. May be it's better to introduce new system table?
>> pg_amorderop
>> to store ordering operations for index.
>
> We could, but that approach doesn't scale to wanting more categories
> in the future --- you're essentially decreeing th
Reflecting on it, it seems to me that the separate SearchSysCacheN()
macros are obviously cleaner and closer to preferred project style than
the existing code with all those explicit zeroes. So I think there's
a case for migrating to that style even if we didn't have a concern
about the max numbe
Robert Haas writes:
> Just to be clear, I was intending this patch, at least, to be applied
> now. I actually think there's a good argument that we should do at
> least this much for 9.0, namely that now is probably the time when
> there are the fewest outstanding patches that will be broken by t
On Sat, Feb 13, 2010 at 2:38 PM, Tom Lane wrote:
> Hitoshi Harada writes:
>> And we don't have time to invent such new world.
>
> Huh? This is all discussion for 9.1 (or even later). There's
> plenty of time.
Just to be clear, I was intending this patch, at least, to be applied
now. I actuall
Robert Haas writes:
> On Sat, Feb 13, 2010 at 3:02 PM, Tom Lane wrote:
>> What would probably be the recommended solution for backwards-compatible
>> source code is to convert the actual calls to new style, and then
>> provide a block of macro definitions along the lines of
>>
>> #if CATALOG_VER
On Sat, Feb 13, 2010 at 3:02 PM, Tom Lane wrote:
> What would probably be the recommended solution for backwards-compatible
> source code is to convert the actual calls to new style, and then
> provide a block of macro definitions along the lines of
>
> #if CATALOG_VERSION_NO < something
> #define
I can't seem to build the PDF version of the documentation on any of my
Ubuntu 9.04 systems, and wonder if there's anything that can/should
should get done about it.
The problem happens like this:
gsm...@gsmith-desktop:~/pgwork/doc/src/sgml$ make postgres-US.pdf
openjade -D . -D . -c
/usr/sh
Robert Haas writes:
> On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley wrote:
>> (Realizing I'm a lurker in this conversation, and hoping not to ask
>> irritating
>> questions) Do we need to rename SearchSysCache et al. to SearchSysCache1,
>> etc.? It seems to me that requires changes to all kinds
Hitoshi Harada writes:
> And we don't have time to invent such new world.
Huh? This is all discussion for 9.1 (or even later). There's
plenty of time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
2010/2/14 Robert Haas :
> If we want to allow 5-key syscaches, we have to add an extra parameter
> to SearchSysCache and friends. So everyone caller of SearchSysCache
> is going to break. (Well, unless we instead leave SearchSysCache
> alone and add SearchSysCacheExtended or similar; but that's n
2010/2/14 Tom Lane :
> Teodor Sigaev writes:
>> I see your point. May be it's better to introduce new system table?
>> pg_amorderop
>> to store ordering operations for index.
>
> We could, but that approach doesn't scale to wanting more categories
> in the future --- you're essentially decreeing
On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley wrote:
> On Sat, Feb 13, 2010 at 01:31:44PM -0500, Robert Haas wrote:
>> On Sat, Feb 13, 2010 at 1:28 PM, Tom Lane wrote:
>> > Teodor Sigaev writes:
>> >> I see your point. May be it's better to introduce new system table?
>> >> pg_amorderop
>> >>
On Sat, Feb 13, 2010 at 01:31:44PM -0500, Robert Haas wrote:
> On Sat, Feb 13, 2010 at 1:28 PM, Tom Lane wrote:
> > Teodor Sigaev writes:
> >> I see your point. May be it's better to introduce new system table?
> >> pg_amorderop
> >> to store ordering operations for index.
> >
> > We could, but
Teodor Sigaev writes:
> I see your point. May be it's better to introduce new system table?
> pg_amorderop
> to store ordering operations for index.
We could, but that approach doesn't scale to wanting more categories
in the future --- you're essentially decreeing that every new category
of opc
On Fri, Feb 12, 2010 at 9:14 AM, Heikki Linnakangas
wrote:
> One glaring issue with the current documentation layout is that the
> documentation for the various options in recovery.conf is split in two
> places.
I've been trying to explain to someone how to set this all up and they
keep asking me
However, that does make it even uglier to have category shoehorned in as
part of a different field. Back to wanting 5-key syscaches ...
Sigh.
I see your point. May be it's better to introduce new system table? pg_amorderop
to store ordering operations for index.
--
Teodor Sigaev
Hi,
Kevin Grittner wrote:
I just got to the point of having what appears to be a working but
poorly optimized version of serializable transactions,
Cool.
so it is
critical that I create a good set of tests to confirm correct
behavior and monitor for regressions as I optimize. I see that
you
Committed, thanks.
On Sun, 2010-02-07 at 21:47 +0100, Andres Freund wrote:
> Hi Simon, Hi all,
>
>
> if (!logged && (wait_s > 0 || wait_us > 50))
> {
> const char *oldactivitymsg;
> int len;
>
> oldactivitymsg = get_ps_display(&len);
> snp
Tim Bunce wrote:
But that's quite different from us providing an undocumented way to
expose arbitrary objects to the Safe container. In that case *we*
become responsible for any insecure uses, and we don't even have the
luxury of having put large warnings in the docs, because there
aren't any d
On 01/02/2010 17:28, Tom Lane wrote:
Matteo Beccati writes:
My main concern is that we'd need to overcomplicate the thread detection
algorithm so that it better deals with delayed messages: as it currently
works, the replies to a missing message get linked to the
"grand-parent". Injecting the m
On Fri, Feb 12, 2010 at 07:57:15PM -0500, Andrew Dunstan wrote:
> Alex Hunsaker wrote:
> > Yes it could allow people who
> >can set the plperl.*_init functions to muck with the safe. As an
> >admin I could also do that by setting plperl.on_init and overloading
> >subs in the Safe namespace or swi
Jeff Davis wrote:
Keep in mind that backwards compatibility is not the only issue here;
forwards compatibility matters as well*. A lot of the encoding issues I
wrote up ( http://wiki.postgresql.org/wiki/Driver_development ) will
probably be real bugs in a python3 application using a driver that
d
Robert Haas wrote:
Recording some bookkeeping information in pg_class so that pg_migrator can tell
what's going on
at a glance seems like the right approach, but I'm fuzzy on the details.
November of 2008 was a pretty good month for me, so I enjoyed this
flashback to it. That's when the p
43 matches
Mail list logo
