Find attached v3 of the patch. changes include:
- fix deep recursion due to accidental reversal of check in encode_array_literal
- add proper support for stringifying composite/row types. I did not
find a good way to quote these from the perl on the fly, so instead we
compute it the same way we u
This is kinda scary .
Oracle guy asking for PostgreSQL documentation and internals of the
optimizer.
On Thu, Jan 27, 2011 at 12:14 AM, Josh Berkus wrote:
> Felix,
>
> > I'm interested in the query optimizer of PostgreSQL DB. Where could I
> > find useful documentation or could you send me
On Wed, Jan 26, 2011 at 09:35:24AM -0500, Robert Haas wrote:
> On Mon, Jan 24, 2011 at 11:13 PM, Noah Misch wrote:
> >> > This helps on conversions like varchar(4)->varchar(8) and text->xml.
> >>
> >> I've read through this patch somewhat. ?As I believe Tom also
> >> commented previously, exemptor
(2011/01/27 0:25), Robert Haas wrote:
> 2011/1/25 KaiGai Kohei:
>> (2011/01/26 12:23), KaiGai Kohei wrote:
> Yikes. On further examination, exec_object_restorecon() is pretty
> bogus. Surely you need some calls to quote_literal_cstr() in there
> someplace.
>>> Are you concerning
On Wed, Jan 26, 2011 at 5:17 AM, Magnus Hagander wrote:
> We should, and the easiest way is to actually use XLogRead() since the
> code is already there. How about the way in this patch?
Thanks for the update. I reread the patch.
+ MemSet(&statbuf, 0, sizeof(statbuf));
+
I've been working closely with Black Duck Software, and their customer,
to get to the bottom of $subject, and we have just declared success.
Here is a summary of the problem and solution for the archives.
The end-customer has a fairly beefy server, lots of RAM and CPUs, and is
running an I/O inten
On Wed, Jan 26, 2011 at 7:59 PM, Simon Riggs wrote:
> On Wed, 2011-01-26 at 13:14 +0900, Fujii Masao wrote:
>
>> When log_checkpoints is enabled, checkpoint logs the number of
>> WAL files created/deleted/recycled, but restartpoint doesn't.
>> This is OK before 9.0 because restartpoint had never c
On Wed, Jan 26, 2011 at 07:52:10PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > text -> xml
>
> BTW, that reminds me of something that I think was mentioned way back
> when, but absolutely fails to fit into any of the frameworks discussed
> here: the mere fact that a type is binary-compatible
Tom Lane wrote:
> Bruce Momjian writes:
> > I can remove this warning by casting the pointer to (void *), rather
> > than (const void *) because that is what the prototype uses on my system
> > uses (libz.so.1.1.4):
>
> > ZEXTERN int ZEXPORTgzwrite OF((gzFile file,
> >
On Wed, Jan 26, 2011 at 07:44:43PM -0500, Tom Lane wrote:
> > numeric(8,2) -> numeric(7,2)
> > varbit(8) -> varbit(7)
> > text -> xml
>
> But how often do those really come up?
I'll speak from my own experience, having little idea of the larger community
experience on this one. I usually don't e
On Wed, Jan 26, 2011 at 7:44 PM, Tom Lane wrote:
> But how often do those really come up? And do you really save that
> much? The table still has to be locked against other users, so you're
> still down, and you're still doing all the reads and computation. I
> don't deny that saving the writes
On Wed, Jan 26, 2011 at 6:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I guess my thought was that we what we were doing is extending
>> the coercion system to be able to make decisions based on both type
>> OID and typemod.
>
> Well, that's an interesting thought, but the proposal at ha
Bruce Momjian writes:
> I can remove this warning by casting the pointer to (void *), rather
> than (const void *) because that is what the prototype uses on my system
> uses (libz.so.1.1.4):
> ZEXTERN int ZEXPORTgzwrite OF((gzFile file,
> const voidp buf, unsig
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Robert Haas wrote:
> > > I recently started getting these:
> > >
> > > plpython.c: In function ?PLy_output?:
> > > plpython.c:3468: warning: format not a string literal and no format
> > > arguments
> > > plpython.c: In function ?PLy_elog?:
> > > pl
Bruce Momjian writes:
>> And I see this warning:
>>
>> compress_io.c:597: warning: passing arg 2 of `gzwrite' discards
>> qualifiers from pointer target type
> I can remove this warning by casting the pointer to (void *), rather
> than (const void *) because that is what the prototype uses on my
Noah Misch writes:
> text -> xml
BTW, that reminds me of something that I think was mentioned way back
when, but absolutely fails to fit into any of the frameworks discussed
here: the mere fact that a type is binary-compatible (with or without
checking) doesn't make it compatible enough to not ha
On Wed, 2011-01-26 at 17:39 -0500, Robert Haas wrote:
> On Wed, Jan 26, 2011 at 5:30 PM, Richard Broersma
> wrote:
> >> I'm not sure what you mean by this.
> >
> > Now that I read it, I not sure what I meant either. :) How about this: the
> > selection, management, and oversight of grants and men
Noah Misch writes:
> On Wed, Jan 26, 2011 at 06:29:57PM -0500, Tom Lane wrote:
>> I remain completely unexcited about optimizing that case, especially if
>> it doesn't fit into a general framework. The bang for the buck ratio
>> is not good: too much work, too much uglification, too little return
On Wed, Jan 26, 2011 at 06:29:57PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > If we hook this into eval_const_expressions, it definitely seems
> > cleaner to attach the auxiliary function to the pg_proc. Otherwise,
> > we'd reconstruct which cast led to each function call -- is there even
>
Bruce Momjian wrote:
> Robert Haas wrote:
> > I recently started getting these:
> >
> > plpython.c: In function ?PLy_output?:
> > plpython.c:3468: warning: format not a string literal and no format
> > arguments
> > plpython.c: In function ?PLy_elog?:
> > plpython.c:3620: warning: format not a st
I wrote:
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
>> after systable_getnext_ordered returned NULL, is it ok to call it again?
> I wouldn't rely on it working.
>> i'm wondering because inv_truncate seems to do it and expecting NULL.
> Hmm, that may well be a bug. Have you tested it?
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > We use small "k" in postgresql.conf, so pg_test_fsync should use the
> > same. Using "kB" would be more accurate in any case.
>
> OK, done with the attached applied patch.
FYI, I had used 'k' because this page suggests that k is 1000 and K is
10
On 27/01/11 00:40, Peter Eisentraut wrote:
> On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
>> Here's an updated patch series for PL/Python refactoring. It was 16
>> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
>
> Everything(*) is now committed.
Great, thanks.
I
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> _2 is only Python 2.2, but I tried: with Python 2.2 there's a whole lot
> of regression tests that fail. The last release of 2.2 is April 2003,
> maybe it's time to forget about that particular dinosaur?
Well, there's little point in carrying an incorrec
On 24/01/11 05:42, Hitoshi Harada wrote:
> 2011/1/23 Jan Urbański :
>> On 22/01/11 11:15, Hitoshi Harada wrote:
> I tested the new incremental patch and the previous example works
> fine. I don't know if this can be handled properly but another example
> is:
>
> regression=# create function func1(
On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
> Here's an updated patch series for PL/Python refactoring. It was 16
> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
Everything(*) is now committed.
In 0006-Improve-exception-usage-in-PL-Python.patch I went for TypeEr
Noah Misch writes:
> If we hook this into eval_const_expressions, it definitely seems
> cleaner to attach the auxiliary function to the pg_proc. Otherwise,
> we'd reconstruct which cast led to each function call -- is there even
> enough information available to do so unambiguously?
As far as th
On 27/01/11 00:15, Tom Lane wrote:
> Peter Eisentraut writes:
>> On ons, 2011-01-26 at 17:47 -0500, Tom Lane wrote:
>>> I was a bit disturbed by the fact that fixing only one of the four
>>> variant files was enough to turn the whole buildfarm green. Are the
>>> other three cases even needed anym
Peter Eisentraut writes:
> On ons, 2011-01-26 at 17:47 -0500, Tom Lane wrote:
>> I was a bit disturbed by the fact that fixing only one of the four
>> variant files was enough to turn the whole buildfarm green. Are the
>> other three cases even needed anymore? If so, how can we get some
>> cover
Felix,
> I'm interested in the query optimizer of PostgreSQL DB. Where could I
> find useful documentation or could you send me a pointer in the source code?
>
> What kind of parallelism does PostgreSQL use for operators, like
> selection or join?
Normally we're very helpful with this kind of in
On Wed, Jan 26, 2011 at 05:32:00PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > Well, if you're positive we're eventually going to want this in
> > pg_proc, we may as well add it now. But I'm not too convinced it's
> > the right general API. The number of people writing exactly x + 0 or
> >
Noah Misch writes:
> On Wed, Jan 26, 2011 at 05:55:37PM -0500, Tom Lane wrote:
>> Actually, I can construct a concrete example where applying this
>> optimization in the parser will do the wrong thing:
>>
>> CREATE TABLE base (f1 varchar(4));
>> CREATE VIEW vv AS SELECT f1::varchar(8) FROM base;
On ons, 2011-01-26 at 17:47 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On lör, 2011-01-22 at 16:36 -0500, Tom Lane wrote:
> >> Peter Eisentraut writes:
> >>> Get rid of the global variable holding the error state
>
> >> The buildfarm doesn't like this patch one bit.
>
> > I have veri
Robert Haas writes:
> Well, I guess my thought was that we what we were doing is extending
> the coercion system to be able to make decisions based on both type
> OID and typemod.
Well, that's an interesting thought, but the proposal at hand is far
more limited than that --- it's only an optimiza
On Wed, Jan 26, 2011 at 05:55:37PM -0500, Tom Lane wrote:
> I wrote:
> > ... Another issue is that premature
> > optimization in the parser creates headaches if conditions change such
> > that a previous optimization is no longer valid --- you may have stored
> > rules wherein the optimization was
I wrote:
> ... Another issue is that premature
> optimization in the parser creates headaches if conditions change such
> that a previous optimization is no longer valid --- you may have stored
> rules wherein the optimization was already applied. (Not sure that
> specific issue applies to casting
On Wed, Jan 26, 2011 at 5:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> Oh, really? I was thinking the logic should go into find_coercion_pathway().
>
> Well, I've been saying right along that it should be in
> eval_const_expressions. Putting this sort of optimization in the parser
> is invar
Peter Eisentraut writes:
> On lör, 2011-01-22 at 16:36 -0500, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> Get rid of the global variable holding the error state
>> The buildfarm doesn't like this patch one bit.
> I have verified your adjustments and fixed up the rest.
I was a bit disturbe
On Wed, Jan 26, 2011 at 13:35, Alexey Klyukin wrote:
>
> On Jan 26, 2011, at 10:08 PM, Alex Hunsaker wrote:
>>> (it's obviously reversed comparing with the original one), but it still
>>> segfaults after I fixed that.
Ahh yep, the reason reversing the check did not fix it is order of
operations
On lör, 2011-01-22 at 16:36 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > Get rid of the global variable holding the error state
>
> The buildfarm doesn't like this patch one bit.
I have verified your adjustments and fixed up the rest.
--
Sent via pgsql-hackers mailing list (pgsql-hac
Excerpts from Tom Lane's message of mié ene 26 19:20:52 -0300 2011:
> Robert Haas writes:
> > On Wed, Jan 26, 2011 at 4:44 PM, Tom Lane wrote:
> >> Ick. That's an awful lot of stuff to have global ignores for.
>
> > The "coverage" directory ignore seems a little icky, but the rest
> > seems unli
Robert Haas writes:
> Oh, really? I was thinking the logic should go into find_coercion_pathway().
Well, I've been saying right along that it should be in
eval_const_expressions. Putting this sort of optimization in the parser
is invariably the wrong thing, because it fails to catch all the
pos
On Wed, Jan 26, 2011 at 5:20 PM, Peter Eisentraut wrote:
> On ons, 2011-01-26 at 17:00 -0500, Robert Haas wrote:
>> More to the point, regardless of whether the warning is reasonable or
>> not, there's tangible value in a warning-free build, which we have had
>> on most of the systems I use until
On Wed, Jan 26, 2011 at 5:30 PM, Richard Broersma
wrote:
>> I'm not sure what you mean by this.
>
> Now that I read it, I not sure what I meant either. :) How about this: the
> selection, management, and oversight of grants and mentees should be opaque
> to the community so as to prevent distract
On Wed, Jan 26, 2011 at 5:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, if you're positive we're eventually going to want this in
>> pg_proc, we may as well add it now. But I'm not too convinced it's
>> the right general API. The number of people writing exactly x + 0 or
>> x * 0 in a q
Peter Eisentraut writes:
> It turns out you need -Wformat-security with newer GCC versions.
Ah-hah.
> We might want to add that to the standard options set.
+1. Probably this will require an extra configure test, but even so
it's well worthwhile.
regards, tom lane
--
Robert Haas writes:
> Well, if you're positive we're eventually going to want this in
> pg_proc, we may as well add it now. But I'm not too convinced it's
> the right general API. The number of people writing exactly x + 0 or
> x * 0 in a query has got to be vanishingly small; I'm not eager to a
On Wed, Jan 26, 2011 at 1:55 PM, Robert Haas wrote:
> I don't think that's it exactly. Basically, if you fund reviewers,
> and we get lots more people doing reviews and they're all great, I'll
> be happy. If you fund reviewers, and we get lots more people doing
> reviews and they're all terrib
Tom Lane wrote:
> I'm still unexcited about the thesis that we should auto-ignore
> the results of any random tool somebody wants to run in their
> source tree.
Hos about just the tools supported by our documentation, configure
file and make file?
-Kevin
--
Sent via pgsql-hackers mailing l
Robert Haas writes:
> On Wed, Jan 26, 2011 at 4:44 PM, Tom Lane wrote:
>> Ick. That's an awful lot of stuff to have global ignores for.
> The "coverage" directory ignore seems a little icky, but the rest
> seems unlikely to pick up anything incidental.
Tying /coverage to the root as in his V2
On ons, 2011-01-26 at 17:00 -0500, Robert Haas wrote:
> More to the point, regardless of whether the warning is reasonable or
> not, there's tangible value in a warning-free build, which we have had
> on most of the systems I use until recently.
I don't disagree that the warnings are valid. I'd j
Robert Haas writes:
> But I think I did get it on a recently-updated Fedora 13 box also, I
> can check if it's important.
F-13 doesn't show it for me. I get the impression from these results
that maybe gcc versions >= about 4.4 have been tweaked to not show it
... which doesn't really seem like
On Wed, Jan 26, 2011 at 5:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 26, 2011 at 4:02 PM, Tom Lane wrote:
>>> I don't mind confining the feature to casts to start with, but it might
>>> be a good idea to specify the check-function API in a way that would let
>>> it be plugged in
Robert Haas writes:
> Yeah, I wasn't aware of that. I'll go revert, but I think I'll also
> add a big fat comment, because this is entirely non-obvious,
What I think would actually be helpful would be to improve the error
message. I'm not sure if it's practical to pass down the specific
reason(
On Wed, Jan 26, 2011 at 4:44 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Building for coverage and running the reports littered my tree with
>> files which should probably be in .gitignore for just such a
>> contingency. Patch attached.
>
> Ick. That's an awful lot of stuff to have global
Robert Haas writes:
> On Wed, Jan 26, 2011 at 4:02 PM, Tom Lane wrote:
>> I don't mind confining the feature to casts to start with, but it might
>> be a good idea to specify the check-function API in a way that would let
>> it be plugged into a more generally available call-simplification hook
>
On Wed, Jan 26, 2011 at 4:50 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
>>> I recently started getting these:
>>>
>>> plpython.c: In function ‘PLy_output’:
>>> plpython.c:3468: warning: format not a string literal and no format
>>> arg
On Wed, Jan 26, 2011 at 4:39 PM, Richard Broersma
wrote:
> So I take it that the concern is not how reviews are funded, but over the
> perceived connection between the organic community and third party
> organizations. This makes sense.
I don't think that's it exactly. Basically, if you fund r
Peter Eisentraut writes:
> On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
>> I recently started getting these:
>>
>> plpython.c: In function âPLy_outputâ:
>> plpython.c:3468: warning: format not a string literal and no format arguments
>> plpython.c: In function âPLy_elogâ:
>> plpy
On Wed, Jan 26, 2011 at 12:29:23PM -0800, Joshua D. Drake wrote:
> On Wed, 2011-01-26 at 14:15 -0500, Robert Haas wrote:
> > On Wed, Jan 26, 2011 at 1:32 PM, Richard Broersma
> > wrote:
> > > On Wed, Jan 26, 2011 at 3:12 AM, Simon Riggs
> > > wrote:
> > >> You're paying the reviewers; are you pa
"Kevin Grittner" writes:
> Building for coverage and running the reports littered my tree with
> files which should probably be in .gitignore for just such a
> contingency. Patch attached.
Ick. That's an awful lot of stuff to have global ignores for.
Perhaps we should recommend people do cover
On Wed, Jan 26, 2011 at 4:20 PM, Peter Eisentraut wrote:
> On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
>> I recently started getting these:
>>
>> plpython.c: In function ‘PLy_output’:
>> plpython.c:3468: warning: format not a string literal and no format arguments
>> plpython.c: In funct
On Wed, Jan 26, 2011 at 1:19 PM, Robert Haas wrote:
> It's just that
> I require both income and sleep. That's probably not an issue for
> people who are just getting started in the community.
>
> Another question is whether you really need assigned mentors at all.
...
>
Very few emails on -ha
"Kevin Grittner" wrote:
> Patch attached.
The coverage directory belongs under "Local excludes in root
directory". Version 2.
-Kevin
*** a/.gitignore
--- b/.gitignore
***
*** 12,19
--- 12,28
*.mo
objfiles.txt
.deps/
+ *.h.gcov
+ *.c.gcov
+ *.y.gcov
+ *.l.gcov
+
On Wed, Jan 26, 2011 at 4:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> Considering the number of OTHER places we'd have to break backward
>> compatibility, one more wouldn't bother me any, but apparently that's
>> just me.
>
> Well, again, it'd be all right with me if we were going to get any
On Wed, Jan 26, 2011 at 4:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 26, 2011 at 3:08 PM, Tom Lane wrote:
>>> Robert Haas writes:
It's not obvious to me that it has a use case outside of casts, but
it's certainly possible I'm missing something.
>
>>> A possible exampl
Peter Eisentraut wrote:
> We use small "k" in postgresql.conf, so pg_test_fsync should use the
> same. Using "kB" would be more accurate in any case.
OK, done with the attached applied patch.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterpr
Robert Haas writes:
> Considering the number of OTHER places we'd have to break backward
> compatibility, one more wouldn't bother me any, but apparently that's
> just me.
Well, again, it'd be all right with me if we were going to get any
meaningful increment in functionality out of it, but we ar
On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
> I recently started getting these:
>
> plpython.c: In function ‘PLy_output’:
> plpython.c:3468: warning: format not a string literal and no format arguments
> plpython.c: In function ‘PLy_elog’:
> plpython.c:3620: warning: format not a string
On Wed, Jan 26, 2011 at 3:29 PM, Joshua D. Drake wrote:
> Not somewhat, completely. Most of the "teachers" we have are already
> getting paid to work on PostgreSQL. There are some exceptions of course
> but if you look at the list of people that are qualified to actually
> review code, they are ge
We use small "k" in postgresql.conf, so pg_test_fsync should use the
same. Using "kB" would be more accurate in any case.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Building for coverage and running the reports littered my tree with
files which should probably be in .gitignore for just such a
contingency. Patch attached.
-Kevin
*** a/.gitignore
--- b/.gitignore
***
*** 12,17
--- 12,26
*.mo
objfiles.txt
.deps/
+ *.h.gcov
+ *.c.gc
Tom Lane writes:
> Oh: then you're doing it wrong. If you want to remember that WITH
> SCHEMA was specified, you need to explicitly store that as another
> column in pg_extension. You should not be depending on the dependency
> mechanism to remember that for you, any more than we'd use pg_depend
Robert Haas writes:
> On Wed, Jan 26, 2011 at 3:08 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> It's not obvious to me that it has a use case outside of casts, but
>>> it's certainly possible I'm missing something.
>> A possible example is simplifying X + 0 to X, or X * 0 to 0.
> Oh, I see.
On Wed, Jan 26, 2011 at 3:48 PM, Tom Lane wrote:
>> Well, actually, what I thought was that the rowtype *should* act
>> exactly like a separately-declared composite rowtype. Which is to
>> say, it shouldn't have a default, because a separately-declared
>> composite rowtype *can't have a default*.
Just a small comment: If someone offered me $15 to mentor a reviewer, I
would tell him to kindly go away. If the same person were to offer me a
$15 t-shirt saying I mentored the review (or whatever), I would consider
it.
Yes, I know I could buy the t-shirt with the money. People are strange
tha
Robert Haas writes:
> On Wed, Jan 26, 2011 at 1:32 PM, Tom Lane wrote:
>> I will agree that a language lawyer could argue that a table rowtype
>> doesn't have to act like a separately-declared composite type, but
>> that surely doesn't meet the POLA.
> Well, actually, what I thought was that the
On Wed, Jan 26, 2011 at 3:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane wrote:
>>> If you didn't mind inverting the sense of the result
>>> then we could use "EXECUTE IF function_name".
>
>> What about borrowing from the trigger syntax?
>
>> WITH FUNC
On Wed, Jan 26, 2011 at 02:36:25PM -0600, Kevin Grittner wrote:
> Same benefit in terms of exercising more lines of code, but
> *without* exposing the uninitialized structure to other threads.
Won't this cause a deadlock because locks are being acquired out of
order?
Dan
--
Dan R. K. Ports
I wrote:
> You're right. How about this?:
That's even worse. I'm putting back to where you had it and taking
a break before I do anything else that dumb.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Dimitri Fontaine writes:
> Tom Lane writes:
>> Mph. Although such an extension should certainly carry a dependency on
>> the schema it's using, I'm not sure that it makes sense to consider that
>> the extension (as opposed to its contained objects) belongs to the
>> schema.
> Well yes, extensio
On Jan 26, 2011, at 10:08 PM, Alex Hunsaker wrote:
> On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin wrote:
>> Hi,
>>
>> On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
>>
>>> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
wrote:
Dan Ports wrote:
> Isn't this placement the same as the version we had before that
> didn't work?
You're right. How about this?:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=86b839291e2588e59875fb87d05432f8049575f6
Same benefit in terms of exercising more
On Wed, 2011-01-26 at 14:15 -0500, Robert Haas wrote:
> On Wed, Jan 26, 2011 at 1:32 PM, Richard Broersma
> wrote:
> > On Wed, Jan 26, 2011 at 3:12 AM, Simon Riggs wrote:
> >> You're paying the reviewers; are you paying the mentors?
> >
> > The answer to this question is that we can fund mentor (
On Wed, Jan 26, 2011 at 01:42:23PM -0600, Kevin Grittner wrote:
> Dan, do you still have access to that machine you were using for the
> DBT-2 runs? Could we get a coverage run with and without
> TEST_OLDSERXID defined?
Sure, I'll give it a shot (once I figure out how to enable coverage...)
Dan
On Wed, Jan 26, 2011 at 10:01:28AM -0600, Kevin Grittner wrote:
> In looking at it just now, I noticed that after trying it in a
> couple different places what was left in the repository was not the
> optimal version for code coverage. I've put this back to the
> version which did a better job, fo
On Wed, Jan 26, 2011 at 1:32 PM, Tom Lane wrote:
>> I think you're conflating the table with its row type, and I'd like to
>> see some prior writing indicating otherwise.
>
> I will agree that a language lawyer could argue that a table rowtype
> doesn't have to act like a separately-declared compo
"Kevin Grittner" wrote:
> Alvaro Herrera wrote:
>
>> BTW did you try "make coverage" and friends? See
>> http://www.postgresql.org/docs/9.0/static/regress-coverage.html
>> and
>> http://developer.postgresql.org/~petere/coverage/
>
> I had missed that; thanks for pointing it out!
>
> I'm d
Robert Haas writes:
> On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane wrote:
>> If you didn't mind inverting the sense of the result
>> then we could use "EXECUTE IF function_name".
> What about borrowing from the trigger syntax?
> WITH FUNCTION function_name (argument_type, [...]) WHEN
> function_t
On Wed, Jan 26, 2011 at 12:44, Alexey Klyukin wrote:
> Hi,
>
> On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
>
>> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
>>> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
>>> wrote:
On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>
On Wed, Jan 26, 2011 at 11:15 AM, Robert Haas wrote:
> Usually, in an educational process, it's the teachers who get paid,
> and the students who have to pay to get educated. I realize this is
> somewhat different because we want to encourage people to get involved
> in the project, but it stil
Tom Lane writes:
> Mph. Although such an extension should certainly carry a dependency on
> the schema it's using, I'm not sure that it makes sense to consider that
> the extension (as opposed to its contained objects) belongs to the
> schema. If we think that extensions live inside schemas then
"David E. Wheeler" writes:
> I think M. Fetter is completely wrong. If people are rethinking
> whether they should volunteer based on whether other people are being
> funded for their time to review patches, we don't want such people
> around anyway. Let them leave.
I can see his concern though:
Dimitri Fontaine writes:
> We could use get_extension_namespace() just after recoding the
> dependency and error out if we don't find the arguments we gave to
> recordDependencyOn() so that we're not duplicating code. That will
> cover any pinned schema. I'm preparing a patch to do that.
Kids a
Hi,
On Jan 26, 2011, at 8:45 PM, Alex Hunsaker wrote:
> On Sat, Jan 15, 2011 at 15:48, Alex Hunsaker wrote:
>> On Wed, Jan 12, 2011 at 13:04, Alexey Klyukin
>> wrote:
>>>
>>> On Jan 12, 2011, at 8:52 PM, David E. Wheeler wrote:
>>>
On Jan 12, 2011, at 5:14 AM, Alexey Klyukin wrote:
Alvaro Herrera wrote:
> BTW did you try "make coverage" and friends? See
> http://www.postgresql.org/docs/9.0/static/regress-coverage.html
> and
> http://developer.postgresql.org/~petere/coverage/
I had missed that; thanks for pointing it out!
I'm doing a coverage build now, to see what cov
Cristiano Duarte writes:
> I was thinking about an old 2007 topic, where schema
> qualification was proposed on the EXPLAIN output
> (http://archives.postgresql.org/pgsql-
> hackers/2007-06/msg00473.php).
> Besides my need for this "feature" for my own PgFoundry
> project (that need to parse
Dimitri Fontaine writes:
> So in his tests, Itagaki was tempted to issue the following statement:
> CREATE EXTENSION adminpack WITH SCHEMA pg_catalog;
> That's supposed to register a dependency from the extension to its
> declared hosting schema (adminpack is not relocatable so that entirely
>
Excerpts from Kevin Grittner's message of mié ene 26 14:07:18 -0300 2011:
> Simon Riggs wrote:
> > Pounding for hours on 16 CPU box sounds good. What diagnostics or
> > instrumentation are included with the patch? How will we know
> > whether pounding for hours is actually touching all relevant p
On Wed, Jan 26, 2011 at 12:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... A side issue is that I really
>> want to avoid adding a new parser keyword for this. It doesn't bother
>> me too much to add keywords for really important and user-visible
>> features, but when we're adding stuff that
1 - 100 of 167 matches
Mail list logo
