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
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
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 switching
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
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);
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
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
On Fri, Feb 12, 2010 at 9:14 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Teodor Sigaev teo...@sigaev.ru 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
On Sat, Feb 13, 2010 at 01:31:44PM -0500, Robert Haas wrote:
On Sat, Feb 13, 2010 at 1:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Teodor Sigaev teo...@sigaev.ru writes:
I see your point. May be it's better to introduce new system table?
pg_amorderop
to store ordering operations for index.
On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley eggyk...@gmail.com 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 t...@sss.pgh.pa.us wrote:
Teodor Sigaev teo...@sigaev.ru writes:
I see your point. May be it's better to introduce
2010/2/14 Tom Lane t...@sss.pgh.pa.us:
Teodor Sigaev teo...@sigaev.ru 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 ---
2010/2/14 Robert Haas robertmh...@gmail.com:
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
Hitoshi Harada umi.tan...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 13, 2010 at 2:03 PM, Joshua Tolley eggyk...@gmail.com 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
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
On Sat, Feb 13, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Feb 13, 2010 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Feb 13, 2010 at 2:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hitoshi Harada umi.tan...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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
Tom Lane t...@sss.pgh.pa.us writes:
Teodor Sigaev teo...@sigaev.ru 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
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
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 simplify
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
I have updated the attached C comment about why we return 0 0 for some
tags.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index:
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
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 it?
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 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
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.
Is
David E. Wheeler da...@kineticode.com 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
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
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
On Sat, Feb 13, 2010 at 3:34 AM, Greg Smith g...@2ndquadrant.com 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
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 commandSELECT/command or commandCREATE TABLE AS/command
command, the tag is SELECT rows... [and the rest as you have it]
We should probably
On Sat, Feb 13, 2010 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Sat, Feb 13, 2010 at 10:15 PM, Bruce Momjian br...@momjian.us 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 commandSELECT/command or commandCREATE TABLE AS/command
command, the tag
Robert Haas robertmh...@gmail.com 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
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;
On Fri, Feb 12, 2010 at 9:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 12, 2010 at 8:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We could possibly put in some hack to disallow OLD/NEW references in
the WITH queries, but that got past my
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
42 matches
Mail list logo
