Itagaki Takahiro writes:
> Sure, and I found there might be difference between "UPDATE" and
> "UPDATE OF {all-columns}" triggers. UPDATE trigger is always fired
> when a row is updated even if none of the columns are actually
> modified, but UPDATE OF {all-columns} trigger is fired only when
> at
Itagaki Takahiro writes:
> But how? First, I tried to use existing dependency mechanism:
> ObjectAddress referenced;
> referenced.classId = AttributeRelationId;
> referenced.objectId = {relid};
> referenced.objectSubId = {attnum};
This is just wrong. The correct representation o
On ons, 2009-09-02 at 12:52 -0700, Joshua D. Drake wrote:
> Isn't "core" supposed to be the release manager?
The core team has historically been the release *maker* and has some
done management of the final phases of that process. But I think the
sentiment is growing that we need more management
2009/9/3 Joshua Tolley :
> On Thu, Sep 03, 2009 at 01:19:25AM +0400, Олег Царев wrote:
>> After week-lengthed investigation, now i 'm sure - my level of
>> qualification not enough for implementation task "GROUPING SETS".
>> I require documentation about the executor and the planner, i can't
>> und
2009/9/2 Олег Царев :
> After week-lengthed investigation, now i 'm sure - my level of
> qualification not enough for implementation task "GROUPING SETS".
> I require documentation about the executor and the planner, i can't
> understand scheme of work by source code.
> Many code, many cases, but v
On Thu, Sep 03, 2009 at 01:19:25AM +0400, Олег Царев wrote:
> After week-lengthed investigation, now i 'm sure - my level of
> qualification not enough for implementation task "GROUPING SETS".
> I require documentation about the executor and the planner, i can't
> understand scheme of work by sourc
Itagaki Takahiro wrote:
>
> David Fetter wrote:
>
> > > It's still arguable that we should add dependencies from column
> > > triggers to referenced columns.
> >
> > +1 for adding the dependencies.
>
> But how? First, I tried to use existing dependency mechanism:
>
> ObjectAddress referen
David Fetter wrote:
> > It's still arguable that we should add dependencies from column
> > triggers to referenced columns.
>
> +1 for adding the dependencies.
But how? First, I tried to use existing dependency mechanism:
ObjectAddress referenced;
referenced.classId = AttributeRelatio
On Wed, Sep 2, 2009 at 10:22 PM, Josh Berkus wrote:
> Robert,
>
>> A. Update the status of patches on the wiki (because the patch authors
>> and reviewers often didn't).
>> B. Poke reviewers or patch authors who didn't respond in a timely
>> fashion and/or move to "Returned with Feedback".
>> C. As
Robert Haas wrote:
> Wow, so I wouldn't have to do this any more?
>
> IF (TG_OP = 'UPDATE') THEN
> IF (OLD.foo IS NOT DISTINCT FROM NEW.foo AND OLD.bar IS NOT
> DISTINCT FROM NEW.bar
> AND OLD.baz IS NOT DISTINCT FROM NEW.baz) THEN
> RETURN NULL;
> END IF;
> END IF;
Su
Robert,
> A. Update the status of patches on the wiki (because the patch authors
> and reviewers often didn't).
> B. Poke reviewers or patch authors who didn't respond in a timely
> fashion and/or move to "Returned with Feedback".
> C. Assign new patches to reviewers who requested them.
> D. Send
On Wed, Sep 2, 2009 at 9:52 PM, Itagaki
Takahiro wrote:
> Here is a patch to implement "Support triggers on columns" in our ToDo list.
>
> The syntax is:
> CREATE TRIGGER name
> BEFORE UPDATE OF col1, col12, ...
> ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
>
> I consulted the pr
On Wed, Sep 2, 2009 at 9:31 PM, Josh Berkus wrote:
> Robert,
>
>> I would like to propose an additional stipulation on CF4 - namely,
>> that we will reject out of hand any large patches that were not
>> submitted to CF3. For the sake of definiteness, let's say that a
>> large patch is anything whe
On Thu, Sep 03, 2009 at 10:52:09AM +0900, Itagaki Takahiro wrote:
> Here is a patch to implement "Support triggers on columns" in our ToDo list.
>
> The syntax is:
> CREATE TRIGGER name
> BEFORE UPDATE OF col1, col12, ...
> ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
Kudos!
Here is a patch to implement "Support triggers on columns" in our ToDo list.
The syntax is:
CREATE TRIGGER name
BEFORE UPDATE OF col1, col12, ...
ON tbl FOR EACH ROW EXECUTE PROCEDURE func();
I consulted the previous work following:
Column-level triggers (From: Greg Sabino
I wrote:
> "Erik Rijkers" writes:
>> While test building from CVS head on fedora 10 (also on fedora 6), I get:
>> initializing pg_authid ... ok
>> setting password ... ok
>> initdb: The password file was not generated. Please report this problem.
>> initdb: removing data directory
>> "/home/super
Robert,
> I would like to propose an additional stipulation on CF4 - namely,
> that we will reject out of hand any large patches that were not
> submitted to CF3. For the sake of definiteness, let's say that a
> large patch is anything whether diffstat run against the unified diff
> shows lines a
"Erik Rijkers" writes:
> While test building from CVS head on fedora 10 (also on fedora 6), I get:
> initializing pg_authid ... ok
> setting password ... ok
> initdb: The password file was not generated. Please report this problem.
> initdb: removing data directory
> "/home/super/pg_stuff/pg_inst
On Wed, Sep 2, 2009 at 7:42 PM, Josh Berkus wrote:
> Hackers,
>
> Per discussions on two other threads on this list which have apparently
> reached consensus, we will be going with the following schedule:
>
> CF1 7/15 to 8/14
> Alpha1 by 8/20
> CF2 9/15 to 10/14
> Alpha2 by 10/20
> CF3
On Wed, Sep 2, 2009 at 8:45 PM, Tom Lane wrote:
> Greg Stark writes:
>> The backwards scan is awful for rotating media. The reading from the
>> end and writing to the beginning is bad too, though hopefully the
>> cache can help that.
>
> Yeah. And all that pales in comparison to what happens in t
On Wed, Sep 2, 2009 at 11:55 PM, Ron Mayer wrote:
> Yet when I try it now, I'm having trouble making it work.
> Would you expect the ctid to be going down in the psql session
> shown below? I wonder why it isn't.
Even before HOT we preferentially tried to put updated tuples on the
same page they
I suppose the initdb invocation is needed as well:
/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla/bin/initdb -U super -D
/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla/data -E UTF8
--pwfile=/home/super/pg_stuff/.84devel
( that .84devel file does exist )
On Thu, September 3, 20
While test building from CVS head on fedora 10 (also on fedora 6), I get:
./configure --prefix=/home/super/pg_stuff/pg_installations/pgsql.cvs_vanilla
--with-pgport=6542
--quiet --enable-depend --with-openssl --with-perl --with-libxml --with-libxslt
gcc (GCC) 4.3.2
compile OK, tests OK, insta
On Sep 2, 2009, at 4:42 PM, Josh Berkus wrote:
CF3 11/15 to 12/14
Alpha3 by 11/20
12/20?
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hackers,
Per discussions on two other threads on this list which have apparently
reached consensus, we will be going with the following schedule:
CF1 7/15 to 8/14
Alpha1 by 8/20
CF2 9/15 to 10/14
Alpha2 by 10/20
CF3 11/15 to 12/14
Alpha3 by 11/20
CF4 1/15 to 2/14
Alpha4 by 2/2
On Wed, Sep 2, 2009 at 5:55 PM, Josh Berkus wrote:
> Robert, Heikki,
>
>> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01651.php
>> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01983.php
>>
>> Josh's schedule was subsequently endorsed by Simon Riggs. So by my
>> count we now
Robert Haas wrote:
> On Tue, Sep 1, 2009 at 9:29 PM, Alvaro
> Herrera wrote:
>> Ron Mayer wrote:
>>> Greg Stark wrote:
That's what I want to believe. But picture if you have, say a
1-terabyte table which is 50% dead tuples and you don't have a spare
1-terabytes to rewrite the whole t
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribi�:
> >> I don't find a lot wrong with that. The code defines its purpose as
> >> being to shorten the table file length. Once it hits a page that
> >> can't be emptied, it cannot shorten the file any further, so why
> >> shouldn't i
Robert, Heikki,
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01651.php
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01983.php
>
> Josh's schedule was subsequently endorsed by Simon Riggs. So by my
> count we now have four votes for a 4-CF schedule and one for a 3-CF
> s
Robert Haas writes:
> Anyway, I'm still curious about what'n'all -core actually does.
Not a lot. That's a feature, not a bug. Most project management
discussion happens on -hackers. If -hackers can't come to a decision
then core will try to resolve the deadlock (assuming we can agree ;-))
but
After week-lengthed investigation, now i 'm sure - my level of
qualification not enough for implementation task "GROUPING SETS".
I require documentation about the executor and the planner, i can't
understand scheme of work by source code.
Many code, many cases, but very little information "what is
On Wed, Sep 2, 2009 at 9:28 PM, Robert Haas wrote:
> Previous emails from Tom seem to indicate that the mandate of -core is
> mostly to decide things like the timing of releases.
That's not all we do.
> If we gave that
> job to somebody else, would there be anything left for -core to do?
> If so,
Robert Haas writes:
> Previous emails from Tom seem to indicate that the mandate of -core is
> mostly to decide things like the timing of releases. If we gave that
> job to somebody else, would there be anything left for -core to do?
> If so, what? And on the flip side, it is precisely because o
On 2 Sep 2009, at 21:38, Alvaro Herrera wrote:
Grzegorz Jaskiewicz escribió:
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
What's with the "analyzer failures"? Did you submit bug reports about
Alvaro Herrera writes:
> Tom Lane escribió:
>> I don't find a lot wrong with that. The code defines its purpose as
>> being to shorten the table file length. Once it hits a page that
>> can't be emptied, it cannot shorten the file any further, so why
>> shouldn't it stop?
> All that work, and i
Tom Lane escribió:
> Alvaro Herrera writes:
> > Another weird consequence of this is that it bails out if it finds a
> > tuple larger than it can fit in one of the earlier pages; if there's
> > dead space to be compacted before that, it's not compacted.
>
> I don't find a lot wrong with that. Th
Grzegorz Jaskiewicz escribió:
> new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
>
> archive one dir up, as usual (with index of all previous reports).
What's with the "analyzer failures"? Did you submit bug reports about
them?
--
Alvaro Herrera
Alvaro Herrera writes:
> Another weird consequence of this is that it bails out if it finds a
> tuple larger than it can fit in one of the earlier pages; if there's
> dead space to be compacted before that, it's not compacted.
I don't find a lot wrong with that. The code defines its purpose as
b
On Wed, Sep 2, 2009 at 4:28 PM, Robert Haas wrote:
> On Wed, Sep 2, 2009 at 4:09 PM, Alvaro
> Herrera wrote:
>> Joshua D. Drake escribió:
>>> On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:
>>> > On Wed, Sep 2, 2009 at 4:57 AM, Heikki
>>> > Linnakangas wrote:
>>> >
>>> > > That implies
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
On Wed, Sep 2, 2009 at 4:09 PM, Alvaro
Herrera wrote:
> Joshua D. Drake escribió:
>> On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:
>> > On Wed, Sep 2, 2009 at 4:57 AM, Heikki
>> > Linnakangas wrote:
>> >
>> > > That implies that we need a release manager. Electing one would be the
>>
On Wed, Sep 2, 2009 at 3:30 PM, Greg Stark wrote:
> On Wed, Sep 2, 2009 at 8:10 PM, Robert Haas wrote:
>> I confess to being a little fuzzy on the details of how this
>> implementation (seq-scanning the source table for live tuples) is
>> different/better from the current VACUUM FULL implementation
Joshua D. Drake escribió:
> On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:
> > On Wed, Sep 2, 2009 at 4:57 AM, Heikki
> > Linnakangas wrote:
> >
> > > That implies that we need a release manager. Electing one would be the
> > > first step. That's a lot of work and responsibility, with
Wolfgang Wilhelm wrote:
> if [ $# -lt 1 -o "$1" = "" ] ] ; then
Oops. Fixed patch attached. Thanks!
-Kevin
Index: contrib/start-scripts/linux-lsb
===
RCS file: contrib/start-scripts/linux-lsb
diff -N contrib/start-scripts/li
Tom Lane escribió:
> Greg Stark writes:
> > It scans pages *backwards* from the end (which does wonderful things
> > on rotating media). Marks each live tuple it finds as "moved off",
> > finds a new place for it (using the free space map I think?).
>
> BTW, VACUUM FULL doesn't use the free space
Hello Kevin,
a technical comment about line 71 and following of your shell script:
# Check that we have one parameter: action
if [ $# -ne 1 ] ; then
if [ $# -lt 1 -o "$1" = "" ] ] ; then
log_failure_msg "$0: action not specified"
else
log_failure_msg "$0: too many parameters"
fi
l
On Wed, 2009-09-02 at 12:50 -0700, Selena Deckelmann wrote:
> On Wed, Sep 2, 2009 at 4:57 AM, Heikki
> Linnakangas wrote:
>
> > That implies that we need a release manager. Electing one would be the
> > first step. That's a lot of work and responsibility, with lots of
> > potential for making peop
On Wed, Sep 2, 2009 at 4:57 AM, Heikki
Linnakangas wrote:
> That implies that we need a release manager. Electing one would be the
> first step. That's a lot of work and responsibility, with lots of
> potential for making people cross, so in practice I think as soon as
> someone steps up to the pl
Greg Stark writes:
> It scans pages *backwards* from the end (which does wonderful things
> on rotating media). Marks each live tuple it finds as "moved off",
> finds a new place for it (using the free space map I think?).
BTW, VACUUM FULL doesn't use the free space map --- that code predates
the
Greg Stark writes:
> The backwards scan is awful for rotating media. The reading from the
> end and writing to the beginning is bad too, though hopefully the
> cache can help that.
Yeah. And all that pales in comparison to what happens in the indexes.
You have to insert index entries (retail) fo
Ohh Thanks to all for your answers,
pgmemcache does exactly what I need, or how I need it, that is to
put my graph into a persistent memory for all transactions that have
permissions.
Thanks again,
Christian Gonzalez
El 02/09/09 14:47, Andrew Dunstan escribió:
Peter Eisentraut wrote:
On Wed, Sep 2, 2009 at 8:10 PM, Robert Haas wrote:
> I confess to being a little fuzzy on the details of how this
> implementation (seq-scanning the source table for live tuples) is
> different/better from the current VACUUM FULL implementation. Can
> someone fill me in?
VACUUM FULL is a *lot* m
Peter Eisentraut wrote:
On ons, 2009-09-02 at 10:59 -0430, Christian Gonzalez wrote:
Is posible to put
persisten object in memory through postgresql c funtion?
Well, the PL/Perl and PL/Python languages do some variants of this using
their GD and SD variables. So it's surely possible
On Wed, Sep 2, 2009 at 11:29 AM, Christian
Gonzalez wrote:
> The point:
> There is some way to keep objects in [persisten] memory and then refer to
> these from c functions?. In the current version of pgRoute, each
> transaction load the graph in memory (using MemoryContext), this isn't a
> enterp
On Wed, Sep 2, 2009 at 2:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> So I have a script that goes and finds bloated tables and runs VACUUM
>> FULL on them in the middle of the night if the bloat passes a certain
>> threshold. The tables are small enough and the number of users is low
>> enoug
On Wed, Sep 2, 2009 at 21:05, Tom Lane wrote:
> Peter Eisentraut writes:
>> On ons, 2009-09-02 at 19:24 +0200, Magnus Hagander wrote:
>>> -kwlookup.c: % : ../../../backend/parser/%
>>> +kwlookup.c: % : $(top_srcdir)/src/backend/parser/%
>>> rm -f $@ && $(LN_S) $< .
>
>> I think you can revert this
Peter Eisentraut writes:
> On ons, 2009-09-02 at 19:24 +0200, Magnus Hagander wrote:
>> -kwlookup.c: % : ../../../backend/parser/%
>> +kwlookup.c: % : $(top_srcdir)/src/backend/parser/%
>> rm -f $@ && $(LN_S) $< .
> I think you can revert this if it helps you, although it's not clear to
> me why
On Wed, Sep 2, 2009 at 2:31 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Wed, Sep 2, 2009 at 6:41 PM, Josh Berkus wrote:
Perhaps we should go one version with a enable_legacy_full_vacuum
which defaults to off. That would at least let us hear about use cases
where people are unhapp
On ons, 2009-09-02 at 10:59 -0430, Christian Gonzalez wrote:
> Is posible to put
> persisten object in memory through postgresql c funtion?
Well, the PL/Perl and PL/Python languages do some variants of this using
their GD and SD variables. So it's surely possible in C as well.
Memory contexts ar
On Wed, Sep 2, 2009 at 6:57 PM, Kevin
Grittner wrote:
> Greg Stark wrote:
>
>> I don't think we want to cluster on the primary key. I think we just
>> want to rewrite the table keeping the same physical ordering.
>
> Well if that's what you want to do, couldn't you do something like?:
>
> Lock the
On ons, 2009-09-02 at 19:24 +0200, Magnus Hagander wrote:
> On Sat, Aug 29, 2009 at 05:26, Tom Lane wrote:
> > pet...@postgresql.org (Peter Eisentraut) writes:
> >> Log Message:
> >> ---
> >> Derived files that are shipped in the distribution used to be built in the
> >> source directory ev
Robert Haas writes:
> So I have a script that goes and finds bloated tables and runs VACUUM
> FULL on them in the middle of the night if the bloat passes a certain
> threshold. The tables are small enough and the number of users is low
> enough that this doesn't cause any problems for me. I'm OK
On ons, 2009-09-02 at 09:13 -0500, Kevin Grittner wrote:
> We don't have the distribution's PostgreSQL package installed on
> any of our machines, so I'd have to install it and risk breaking
> something to even have a look at it.
Using Midnight Commander is the canonical way to peek inside uninsta
On Wed, Sep 2, 2009 at 1:52 PM, Greg Stark wrote:
> We could deal with the admin scripts by making VACUUM FULL do the new
> behaviour. But I actually don't really like that. I wold prefer to
> break VACUUM FULL since anyone doing it routinely is probably
> mistaken.
So I have a script that goes an
Greg Stark writes:
> On Wed, Sep 2, 2009 at 6:41 PM, Josh Berkus wrote:
>>> Perhaps we should go one version with a enable_legacy_full_vacuum
>>> which defaults to off. That would at least let us hear about use cases
>>> where people are unhappy with a replacement.
>>
>> I think we do need to do
Andrew Dunstan writes:
> Kevin Grittner wrote:
>> So while OpenSuse seems a little less restrictive, it's still not
>> something we can copy into the PostgreSQL distribution, right?
> right.
Right. Your clean-room approach seems to have been the right thing.
regards, to
On Wed, 2009-09-02 at 11:01 -0700, Josh Berkus wrote:
> Greg,
>
> > I don't think we want to cluster on the primary key. I think we just
> > want to rewrite the table keeping the same physical ordering.
>
> Agreed.
Are we sure about that? I would argue that the majority of users out
their (think
Greg,
> I don't think we want to cluster on the primary key. I think we just
> want to rewrite the table keeping the same physical ordering.
Agreed.
> Well I've certainly seen people whose disks are more than 50% full.
> They tend to be the same people who want to compact their tables. I
> can't
Greg Stark wrote:
> I don't think we want to cluster on the primary key. I think we just
> want to rewrite the table keeping the same physical ordering.
Well if that's what you want to do, couldn't you do something like?:
Lock the table.
Prop all indexes
Pass the heap with two pointers, one
On Wed, Sep 2, 2009 at 6:41 PM, Josh Berkus wrote:
> All,
>
>
>> I'm having a hard time believing that VACUUM FULL really has any
>> interesting use-case anymore.
>
> Basically, for:
> a) people who don't understand CLUSTER (easily fixed, simply create a
> VACUUM FULL command which just does CLUSTE
On Wed, 2009-09-02 at 10:41 -0700, Josh Berkus wrote:
> All,
>
>
> > I'm having a hard time believing that VACUUM FULL really has any
> > interesting use-case anymore.
>
> Basically, for:
> a) people who don't understand CLUSTER (easily fixed, simply create a
> VACUUM FULL command which just doe
All,
> I'm having a hard time believing that VACUUM FULL really has any
> interesting use-case anymore.
Basically, for:
a) people who don't understand CLUSTER (easily fixed, simply create a
VACUUM FULL command which just does CLUSTER on the primary key)
b) people who are completely out of space
On Wed, Sep 2, 2009 at 19:34, Zeugswetter Andreas OSB
sIT wrote:
>> I'm getting this same error and wonder if Tom's fix is sufficient.
>>
>> IPPROTO_IPV6 is defined in wd2def.h IF _WIN32_WINNT >= 0x0501, but in
>> pg_config_os.h _WIN32_WINNT is DEFINED as 0x0500 so
>> IPPROTO_IPV6 is left
>> undefi
> I'm getting this same error and wonder if Tom's fix is sufficient.
>
> IPPROTO_IPV6 is defined in wd2def.h IF _WIN32_WINNT >= 0x0501, but in
> pg_config_os.h _WIN32_WINNT is DEFINED as 0x0500 so
> IPPROTO_IPV6 is left
> undefined.
>
> Regards,
> Dave
>
> ---
> Unfortunatel
2009/9/2 Tom Lane :
> Pavel Stehule writes:
>> create table x1 (a integer);
>> insert into x1
>> values(2),(2),(3),(3),(4),(4),(5),(5),(6),(6),(6),(8),(9),(9),(10),(10);
>
>> postgres=# select row_number() over (order by a), row_number() over
>> (order by a desc) from x1;
>> row_number | row_num
Andrew Dunstan writes:
> David E. Wheeler wrote:
>> Is there any reason that the CREATE VIEW output to pg_dump and,
>> presumably, \ev, couldn't be refactored to pretty-print the VIEW
>> declaration?
> Tom just said a day or two ago that he doesn't want pg_dump using any
> pretty printing, and
Michael Nacos writes:
> The interesting thing is SQL_exec(sql,1) resulted in a different
> execution plan while the stray FROM was still in place.
Well, the stray FROM resulted in a useless cross-join, which would
have generated a lot of extra no-op row updates. I think what the
limit was doing
David E. Wheeler wrote:
On Sep 2, 2009, at 5:07 AM, Merlin Moncure wrote:
One reason I don't like this proposal is that postgresql does not
preserve the original 'create view' statement for editing. The
resulting sql that is given to you to edit is hopelessly mangled and I
think it's not goo
On Sep 2, 2009, at 5:07 AM, Merlin Moncure wrote:
One reason I don't like this proposal is that postgresql does not
preserve the original 'create view' statement for editing. The
resulting sql that is given to you to edit is hopelessly mangled and I
think it's not good to encourage people to mo
This is from within SPI_exec:
Nested Loop (cost=0.00..115947.18 rows=1952242 width=25) (actual
time=0.095..6425.291 rows=1952202 loops=1)
-> Index Scan using othertable_level_pkey on othertable
(cost=0.00..9.34 rows=1 width=25) (actual time=0.063..0.067 rows=1
loops=1)
Index Cond: ((le
On Wed, 2009-09-02 at 10:21 -0400, Andrew Dunstan wrote:
>
> Umm, no, you could either install the SRPM in a build directory, and
> look there, or extract the script from the built RPM using rpm2cpio.
... actually I am maintaining SuSE spec and patches unofficially in RPM
repository:
https://pr
Hi everybody,
I am new PostgreSQL c function programmer. I'm trying to move ahead
a new "PostgreSQL routing library" (http://www.pgroute.org [for now, the
page in only in spanish]).
The point:
There is some way to keep objects in [persisten] memory and then refer
to these from c functions?
Kevin Grittner wrote:
Andrew Dunstan wrote:
Kevin Grittner wrote:
[SuSE Linux Enterprise Server license]
Novell reserves all rights not expressly granted to You. You may
not:
(2) transfer the Software or Your license rights under this
Agreement, in whole or in part.
Michael Nacos writes:
> the only thing I can tell from EXPLAIN ANALYZE is how long the trigger took
I was thinking of doing EXPLAIN ANALYZE via SPI_exec and seeing if you
got the same results as doing it manually.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Andrew Dunstan wrote:
> Kevin Grittner wrote:
>> [SuSE Linux Enterprise Server license]
>> Novell reserves all rights not expressly granted to You. You may
>> not:
>> (2) transfer the Software or Your license rights under this
>> Agreement, in whole or in part.
> here is what's in what I got
Itagaki Takahiro writes:
> WARNING: getopt(p) = ostgres
> FATAL: attempted change of parameter "port" ignored
> The first argument 'postgres' was interpreted as "-p ostgres" by getopt().
Ugh.
> We might need to re-initilaize variables for getopt() because we call
> process_postgres_sw
Kevin Grittner wrote:
I tracked down the license text. It includes these sections, which
leave me disinclined to copy the init script to the PostgreSQL contrib
directory:
The Software is a collective work of Novell.
You must acquire a license for each
installation of the Software and for
Hi Tom,
the only thing I can tell from EXPLAIN ANALYZE is how long the trigger took
Index Scan using some_pkey on sometable (cost=0.00..8.58 rows=1 width=253)
(actual time=0.046..0.050 rows=1 loops=1)
Index Cond: (pkey = 123456)
Trigger so_and_so_on_change: time=62.309 calls=1
running an equ
Greg Stark wrote:
> Kevin Grittner wrote:
>> # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany.
>> # All rights reserved.
>>
>> and that I would be violating that copyright by copying it to
>> PostgreSQL. Am I wrong?
>
> The above is just a statement of fact. It doesn't change th
Pavel Stehule writes:
> create table x1 (a integer);
> insert into x1
> values(2),(2),(3),(3),(4),(4),(5),(5),(6),(6),(6),(8),(9),(9),(10),(10);
> postgres=# select row_number() over (order by a), row_number() over
> (order by a desc) from x1;
> row_number | row_number
> +--
Gokulakannan Somasundaram writes:
> Well, i am at a very beginner level with Flex. I could see how flex works
> with it even if it is a ambiguity. Since it matches the rule with the
> maximum text and we don't allow a new line character in the rule, it works
> fine. Even in LL(1), it works fine,
On Wed, Sep 2, 2009 at 3:13 PM, Kevin
Grittner wrote:
> # Copyright (c) 2006 SUSE Linux Products GmbH, Nuernberg, Germany.
> # All rights reserved.
>
> and that I would be violating that copyright by copying it to
> PostgreSQL. Am I wrong?
The above is just a statement of fact. It doesn't change
Kevin Grittner wrote:
(2) We don't have the distribution's PostgreSQL package installed on
any of our machines, so I'd have to install it and risk breaking
something to even have a look at it.
Umm, no, you could either install the SRPM in a build directory, and
look there, or extrac
Michael Nacos writes:
> I have been trying to improve the performance of a C trigger only to notice
> that the real bottleneck was the SPI execution of dynamic SQL statements. I
> had been using SPI_exec(sql,0) until I tried SPI_exec(sql,1), since I am
> targeting exactly one row each time for wri
Peter Eisentraut wrote:
> On tis, 2009-09-01 at 12:04 -0500, Kevin Grittner wrote:
>> I wouldn't expect a packaged SuSE build to cater to all of that;
>> but it would be nice if they donated their init script to the
>> PostgreSQL project, so that those of us who have a reason to build
>> from so
On Wed, Sep 2, 2009 at 6:30 AM, Jaime
Casanova wrote:
> On Tue, Sep 1, 2009 at 9:55 PM, Robert Haas wrote:
>>
>> I'm a bit skeptical about partitioning as a solution, too. The
>> planner is just not clever enough with partitioned tables, yet.
Yeah, we need to fix that :)
I think we're already re
Hi all,
I have been trying to improve the performance of a C trigger only to notice
that the real bottleneck was the SPI execution of dynamic SQL statements. I
had been using SPI_exec(sql,0) until I tried SPI_exec(sql,1), since I am
targeting exactly one row each time for writing. This simple chan
On Tue, Sep 1, 2009 at 2:41 PM, Josh Berkus wrote:
> All,
>
> I've grown to adore the new \ef function editor.
>
> It doesn't seem like it would be that difficult to add a view editor as
> \ev. While editors would also be good for other objects, I don't think
> we can do \et or \er etc. because th
Hello,
I wrote article about statistical function - when I tested Joe Celko's
method, I found some problems on not unique dataset:
on distinct dataset is rule so rows here is max(hi), then there is min(lo):
create table x1 (a integer);
insert into x1 select generate_series(1,10);
postgres=# se
Robert Haas wrote:
> I think this is a good illustration of the problems with
> decision-making in a community environment - given choices "3" and "4"
> most of the votes were somewhere between "3.25" and "3.75". I think,
> in general, that when people weigh in with clear opinions, we're
> pretty
1 - 100 of 103 matches
Mail list logo
