Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> I'll admit that I had hopes for it for PR reasons, which
>> is not usually why we make decisions. It would be cool to be the first
>> database system to ship with any implementation of Full Disjunctions, and
>> I can't announce
On 8/13/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
>>> There's been some talk about prohibiting flattening if there are any
>>> volatile functions in the subselect's targetlist, but nothing's been
>>> done about that.
> BTW, can you think in a good name
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This issue is closed, right?
>
> We've agreed we need two functions, but it's not done yet. Seems pretty
> trivial though ...
OK, that's what I was unclear about.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This issue is closed, right?
We've agreed we need two functions, but it's not done yet. Seems pretty
trivial though ...
regards, tom lane
---(end of broadcast)---
TIP 3: Have you
This issue is closed, right?
---
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Something Hannu wrote has just reminded me that
> > pg_current_xlog_location() returns the current Insert pointer rather
> > than
FYI, I will be at LinuxWorld San Francisco tomorrow(Monday) through
Friday. I will have only occasional Internet connectivity, so there
might be delays in my handling open issues.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard dri
Tom Lane wrote:
> With STRICT: you get an error unless exactly one row is affected.
>
> This prevents the incomplete-execution problem.
>
> BTW, some googling indicates that Oracle's equivalent PL/SQL construct
> supports only the exactly-one-row case. But they have an alternative,
> which is th
OK, with two people now concerned, patch reverted.
---
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > I've always found it easier to review uncommitted patches than committed
> > ones anyway. When you're playing catch-up
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not sure that I see the point of this at all. ISTM the entire
>> reason for using a cursor is that you're going to fetch the results
>> in bite-size pieces. I don't see the current Postgres source code
>> surviving into the era wh
Susanne Ebrecht wrote:
> > That's what I was thinking. Glad someone else replied. ;-)
> >
> If you're looking for votes, +1. I'll gladly take a subset of the
> SQL standard UPDATE table SET (...) = (...) over having nothing.
>
> >>> +1 here, too. :)
> >>
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I don't think this is the right approach. Maybe it would be reasonable
> > to add another arm to the %union instead, not sure. The problem is the
> > amount of ugly casts you have to use below. The scanner code seems to
> > think t
Josh Berkus wrote:
I'll admit that I had hopes for it for PR reasons, which
is not usually why we make decisions. It would be cool to be the first
database system to ship with any implementation of Full Disjunctions, and
I can't announce that if it's on pgFoundry.
I don't see that hav
Tom Lane wrote:
I've always found it easier to review uncommitted patches than committed
ones anyway. When you're playing catch-up by reviewing a committed
patch, you have to deal with three states of the code rather than two
(pre-patch, post-patch, your own mods). That gets rapidly worse if
Tom,
> Could we see a concrete, real-world example? So far I've seen a lot of
> arm-waving but nothing very specific.
Sure. Imagine that you work for an arts nonprofit and you have 3 (or more)
separate box office lists from last season, each of which has different
amounts of contact informati
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I don't think this is the right approach. Maybe it would be reasonable
> to add another arm to the %union instead, not sure. The problem is the
> amount of ugly casts you have to use below. The scanner code seems to
> think that a constant larger than
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This reminds me that even though the V3-protocol code has been in there
>> since 7.4, we don't have nearly complete test coverage on it. It'd be a
>> good idea to have some basic tests included somewhere in the standard or
>> contrib
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
>>> There's been some talk about prohibiting flattening if there are any
>>> volatile functions in the subselect's targetlist, but nothing's been
>>> done about that.
> BTW, can you think in a good name for a GUC for this?
I'm not in favor of a GUC for
Josh Berkus writes:
> The reason why it makes sense for FD to be in /contrib is that if it
> works out it will be a new join type, which is definitely core-code stuff.
You seem to have missed my point, which is that implementation as a new
join type would probably have nothing in common with the
Josh Berkus writes:
> Bruce Momjian wrote:
>> I am still waiting for someone to tell us that they would use this
>> capability for a real-world problem.
> It's extremely useful for data mining and data consolidation where
> you're given messy or sparse data to "clean up" and present intelligentl
Tom Lane wrote:
> I wrote:
> > We could "fix" this by emitting the log message before calling
> > finish_xact_command, but I think that would result in seriously
> > underreporting the time required for a COMMIT. Probably the right fix
> > is to copy the data we might need out of the Portal before
I wrote:
> We could "fix" this by emitting the log message before calling
> finish_xact_command, but I think that would result in seriously
> underreporting the time required for a COMMIT. Probably the right fix
> is to copy the data we might need out of the Portal before committing.
Patch applie
> There's been some talk about prohibiting flattening if there are any
> volatile functions in the subselect's targetlist, but nothing's been
> done about that. Disabling flattening is a sufficiently big hit to
> the planner's optimization ability that it shouldn't be done lightly.
>
>
Josh,
I agree entirely with your thoughts - we have to innovate to stay ahead and be
noticed. Unless there are real code problems, let's include FD in /contrib.
Regards, Dave
Regards, Dave
-Original Message-
From: "Josh Berkus"
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc: "David Fetter" <[E
On 8/13/06, Josh Berkus wrote:
My sentiments exactly.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED]
Iselin, New Jersey 08830| http://www.enterprisedb.com/
Tom,
The case for FD seems to be basically "if you build it they will come",
and I'm sorry but I'm not sold. If it gets some traction as a pgfoundry
project then we could look at doing a second-generation implementation
in a form that could actually get into core... but until then I'm
inclined
Bruce Momjian wrote:
I am still waiting for someone to tell us that they would use this
capability for a real-world problem.
It's extremely useful for data mining and data consolidation where
you're given messy or sparse data to "clean up" and present intelligently.
For example, if it had ex
I wrote:
> It may be worth doing the SIGKILL on Unix even if we don't have a
> solution for Windows, but it'd be nice if to have a solution for
> the Windows port too.
I've applied a trivial patch to do the SIGKILL on non-Windows machines.
If any Windows gurus can make it work on Windows too, go f
Bruce Momjian wrote:
Robert Treat wrote:
On Saturday 12 August 2006 16:16, David Fetter wrote:
On Fri, Aug 11, 2006 at 05:11:03PM -0500, Jim C. Nasby wrote:
On Fri, Aug 11, 2006 at 10:59:45AM -0400, Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not sure whether there's anything much we can do to prevent such
>> problems in future. Maybe it'd be reasonable for pg_regress to do a
>> kill -9 on its postmaster child process if it gives up waiting for the
>> postmaster to acc
Jonah's patch for INSERT/etc RETURNING included changes to allow the
RETURNING data to be assigned to plpgsql variables, similar to plpgsql's
version of SELECT INTO. For instance, collect a serial column's
assigned value with
declare x int;
begin
insert into mytab (data)
Bruce Momjian <[EMAIL PROTECTED]> writes:
> There were three things wrong with the original patch:
> o spacing, e.g. "if( x =- 1 )"
> o an incorrect API for memory freeing by parse_value()
> o verify_config_option() didn't consider custom variables
> These have all been corre
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Sat, Aug 12, 2006 at 11:29:46AM -0400, Tom Lane wrote:
> > What's happened is that that GUC patch that was in the tree for a few
> > hours broke postmaster startup on some machines (for as-yet-unidentified
> > reasons). The postmas
On Wed, Aug 09, 2006 at 08:31:42AM -0400, Perez wrote:
> Every once in a while people talk about collecting better statistics,
> correlating multi-column correlations etc. But there never seems to be
> a way to collect that data/statistics.
>
> Would it be possible to determine the additional
ohp@pyrenet.fr writes:
> Since last night, Warthog build farm member (unixware) is failing the
> returning regression test.
Mea culpa --- the regression test was unintentionally displaying
processing-order-dependent behavior, by joining an updated row to
more than one row of another table. Should
Tom Lane wrote:
BTW, do I need to mention that the plperl patch is breaking the
buildfarm again?
No :-) See my comments from about an hour ago. It needs to be removed also.
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' t
David Fetter <[EMAIL PROTECTED]> writes:
> If it were just me laying out the boundary, I'd say that anything that
> changes the grammar of SQL--for example, adding FULL
> DISJUNCTION--can't really be a viable trial outside the main
> distribution channels and deserves a couple of versions' stay in
Michael Fuhr <[EMAIL PROTECTED]> writes:
> The latest HEAD is segfaulting on startup if I have the following
> lines in postgresql.conf:
> custom_variable_classes = 'plperl'
> plperl.use_strict = on
Bruce, please re-revert that GUC patch and don't put it back in until
someone like Peter or me has
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Is anybody working on Bernd's updatable views patch? Right now I'm
> having a look at it -- mainly fixing some cosmetic issues right now,
> intending to eventually do an actual code review.
Great --- it's on my to-do list but I'm happy to have more eye
David Fetter wrote:
If it were just me laying out the boundary, I'd say that anything that
changes the grammar of SQL--for example, adding FULL
DISJUNCTION--can't really be a viable trial outside the main
distribution channels and deserves a couple of versions' stay in one
of those channels if
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> I don't see the harm in including this one for at least this release.
> If no one uses it, take it out for 8.3.
Once stuff is in contrib, it tends to stay there. The above argument
is completely disingenuous --- we'd have to have the same argument
a
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I'm also sending The output from strace (during the execution of the test
> program which I have sent before) showing what jdbc is sending to the
> backend.
Great, I was just going to ask for that.
I can reproduce it in HEAD pretty trivially us
On Sun, Aug 13, 2006 at 11:45:43AM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > > Our distribution is not a place to experiment with things.
> > > That's what separate pgfoundry projects are for. The fact we
> > > have some unusual things in /contrib is not a reason to add
> > > more.
> >
Robert Treat wrote:
> On Saturday 12 August 2006 16:16, David Fetter wrote:
> > On Fri, Aug 11, 2006 at 05:11:03PM -0500, Jim C. Nasby wrote:
> > > On Fri, Aug 11, 2006 at 10:59:45AM -0400, Bruce Momjian wrote:
> > > > Peter Eisentraut wrote:
> > > > > Bruce Momjian wrote:
> > > > > > Are we sure w
On Saturday 12 August 2006 16:16, David Fetter wrote:
> On Fri, Aug 11, 2006 at 05:11:03PM -0500, Jim C. Nasby wrote:
> > On Fri, Aug 11, 2006 at 10:59:45AM -0400, Bruce Momjian wrote:
> > > Peter Eisentraut wrote:
> > > > Bruce Momjian wrote:
> > > > > Are we sure we don't want the patch for a non
David Fetter wrote:
> > Our distribution is not a place to experiment with things. That's
> > what separate pgfoundry projects are for. The fact we have some
> > unusual things in /contrib is not a reason to add more.
>
> If it's on track to become part of PostgreSQL, as other innovative
> featu
On Sun, Aug 13, 2006 at 10:07:06AM -0400, Bruce Momjian wrote:
> Jonah H. Harris wrote:
> > On 8/12/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > > More seriously: the current state of affairs is that the
> > > full-disjunction code exists as a pgfoundry project. If it's
> > > indeed the second grea
Michael Fuhr wrote:
> The latest HEAD is segfaulting on startup if I have the following
> lines in postgresql.conf:
>
> custom_variable_classes = 'plperl'
> plperl.use_strict = on
>
> If I comment out the second line then the server starts successfully.
> Platform is Solaris 9/sparc.
>
> (gdb) b
Hi all,
Since last night, Warthog build farm member (unixware) is failing the
returning regression test.
Regression.diffs is :
*** ./expected/returning.outSat Aug 12 04:52:06 2006
--- ./results/returning.out Sun Aug 13 14:51:07 2006
***
*** 155,162
WHERE foo.f1 = i.q1
Alvaro Herrera wrote:
> Hi,
>
> Is anybody working on Bernd's updatable views patch? Right now I'm
> having a look at it -- mainly fixing some cosmetic issues right now,
> intending to eventually do an actual code review.
>
> I'll post an updated patch at some point -- if someone wants to have a
Jonah H. Harris wrote:
> On 8/12/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> > More seriously: the current state of affairs is that the
> > full-disjunction code exists as a pgfoundry project. If it's indeed the
> > second greatest thing since sliced bread, then I think we could assume
> > that peop
In article <[EMAIL PROTECTED]>,
Perez <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Tom Lane) wrote:
>
> > Martijn van Oosterhout writes:
> > > My main problem is that selectivity is the wrong measurement. What
> > > users really want to be able to communica
The latest HEAD is segfaulting on startup if I have the following
lines in postgresql.conf:
custom_variable_classes = 'plperl'
plperl.use_strict = on
If I comment out the second line then the server starts successfully.
Platform is Solaris 9/sparc.
(gdb) bt
#0 0xff0340a0 in strcmp () from /usr/
52 matches
Mail list logo
