On Wed, 2004-04-21 at 22:43, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Rod Taylor wrote:
>
> > We have the current issue of people not knowing that projects like
> > pgadmin exist or where to find the jdbc drivers.
>
> Agreed ... but makign one big META package isn't going to fix that ... as
> The point of projects.postgresql.org is that if someone *is* looking for
> an addon, they should be pointed to projects.postgresql.org ... if you try
> and merge everything into the -core distribution, you are either going to
> miss something that *someone* wants to use at some point, *or* one he
On Thu, Apr 22, 2004 at 12:41:28AM +0400, Oleg Bartunov wrote:
> The problem with moving all contribs to gborg is that sometimes it's
> required to change many modules, for example, because of changing
> GiST interface. Tom saves a lot of working for contrib authors, when he
> change code in core.
Marc G. Fournier wrote:
On Wed, 21 Apr 2004, Joe Conway wrote:
- It is dependent on backend code to the extent that it cannot be built
outside of the contrib folder, unless some backend code is duplicated
in the external project. It also has no build system of its own.
k, so this one falls unde
Neil Conway <[EMAIL PROTECTED]> writes:
> Any thoughts on what could be causing these errors?
I suspect valgrind is complaining because XLogInsert is memcpy'ing a
struct that has allocation padding in it. Which of course is a bogus
complaint ...
regards, tom lane
---
Hello,
I believe that one problem with the contrib is that in order to build
most of the contrib modules you need
the PostgreSQL source. That is silly. If I have PostgreSQL installed
with all headers, I should be able to
download a PostgreSQL project app (pgAdmin whatever) and just build it
ag
Rod Taylor wrote:
I think most of the current contrib projects are more missing the
advantage version independence would have for the ease of "sitting" in
contrib and having the whole project management around them just done.
Yes, doing your own gborg project costs time. You have to maintain
p
I wrote earlier:
> alvherre=# commit;
> ERROR: cannot drop active portal
>
> This happens while PortalDrop() tries to drop an active portal. In this
> state, I can't do anything else short of closing the connection. But
> this doesn't happen if I try to run a non-utility bogus statement
> ("SE
On Wed, Apr 21, 2004 at 11:47:11PM -0300, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Joe Conway wrote:
> > - dblink-type capability should someday make it into the backend, albeit
> >in the form of something compliant to the SQL/MED spec. This is
> >standard functionality in many of th
On Thu, Apr 22, 2004 at 12:29:36AM -0400, Bruce Momjian wrote:
> I am thinking they could untar into a directory under pgsgl/ or have a
> way to point to a 'configure'-run source tree and pull values from
> there.
>
> If you include pg_config.h, or use Makefile.global, you have almost
> everythin
Bruce Momjian wrote:
I am thinking they could untar into a directory under pgsgl/ or have a
way to point to a 'configure'-run source tree and pull values from
there.
If you include pg_config.h, or use Makefile.global, you have almost
everything you need to compile your own, including flags, config
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Why is a portal kept active after a utility statement fails?
I think you've broken AtAbort_Portals ...
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe
Joe Conway wrote:
> Bruce Momjian wrote:
> > I was thinking about CPAN. They have download stuff, but it installs
> > very easily. I wonder if we should allow gborg projects to interface to
> > our configure output in a way that makes it easier for them to be
> > installed.
>
> Now that idea I l
Bruce Momjian wrote:
I was thinking about CPAN. They have download stuff, but it installs
very easily. I wonder if we should allow gborg projects to interface to
our configure output in a way that makes it easier for them to be
installed.
Now that idea I like. The R project also has something sim
Joe Conway wrote:
Marc G. Fournier wrote:
Why is it the core developers responsibility to make sure that an
application stays in sync with the main tree? Personally, that is giving
life to software that could just as easily be unused by anyone, but kept
in the code base because "a commit was made
On Wed, 21 Apr 2004, Joe Conway wrote:
> Well, in the case of dblink, consider this:
>
> - It is used by a fair number of people -- questions are answered on the
>lists at least once a week with "see contrib/dblink".
A fair # of ppl are using erserver/bsd too ... should we add that in too?
>
Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Bruce Momjian wrote:
>
> > I was thinking about CPAN. They have download stuff, but it installs
> > very easily. I wonder if we should allow gborg projects to interface to
> > our configure output in a way that makes it easier for them to be
> > ins
On Wed, 21 Apr 2004, Rod Taylor wrote:
> We have the current issue of people not knowing that projects like
> pgadmin exist or where to find the jdbc drivers.
Agreed ... but makign one big META package isn't going to fix that ... as
someone else suggested, put a README file in the contrib directo
On Wed, 21 Apr 2004, Bruce Momjian wrote:
> I was thinking about CPAN. They have download stuff, but it installs
> very easily. I wonder if we should allow gborg projects to interface to
> our configure output in a way that makes it easier for them to be
> installed.
No, because again that requ
On Wed, 2004-04-21 at 21:29, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Rod Taylor wrote:
>
> > > I think most of the current contrib projects are more missing the
> > > advantage version independence would have for the ease of "sitting" in
> > > contrib and having the whole project management
Hackers,
While playing with code to enable subtransactions in the storage
manager, I run across this strangeness:
alvherre=# begin; begin;-- start a subtransaction
BEGIN
BEGIN
alvherre=# drop table foo; -- no such table
ERROR: no existe la tabla "foo"
Marc G. Fournier wrote:
Why is it the core developers responsibility to make sure that an
application stays in sync with the main tree? Personally, that is giving
life to software that could just as easily be unused by anyone, but kept
in the code base because "a commit was made to it less then 6
Magnus Hagander wrote:
>
> IMHO it's not all that important where the source is developed (core
> cvs, gborg etc) - whichever suits the development/release model best
> shuold be used (meaning inside core only if it should be released on the
> very same schedule as the main backend only).
>
> Wh
On Wed, 21 Apr 2004, Rod Taylor wrote:
> > I think most of the current contrib projects are more missing the
> > advantage version independence would have for the ease of "sitting" in
> > contrib and having the whole project management around them just done.
> > Yes, doing your own gborg project c
> I think most of the current contrib projects are more missing the
> advantage version independence would have for the ease of "sitting" in
> contrib and having the whole project management around them just done.
> Yes, doing your own gborg project costs time. You have to maintain
> pages, do
Marc G. Fournier wrote:
On Wed, 21 Apr 2004, scott.marlowe wrote:
I almost agree, but I think things that are being actively developed to
eventually move into the backend, like autovacuum or slony-I should be in
contrib. Things that aren't destined for backend integration should be
removed though
The thing is, for how many ppl are seperate packages difficult? I know
for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and
type 'make install' and its done ... I thought that stuff like Redhat had
the full screen installer that lists things?
Well, if setup correctly for redhat
On Thu, 22 Apr 2004, Magnus Hagander wrote:
>
> IMHO it's not all that important where the source is developed (core
> cvs, gborg etc) - whichever suits the development/release model best
> shuold be used (meaning inside core only if it should be released on the
> very same schedule as the main ba
On Wed, 21 Apr 2004, Jan Wieck wrote:
> Joe Conway wrote:
>
> > Jan Wieck wrote:
> >> Taking into account that quite a few people have repeatedly stated that
> >> the components in contrib are considered more supported/recommended than
> >> similar solutions found on gborg or any other external si
On Wed, 21 Apr 2004, scott.marlowe wrote:
> I almost agree, but I think things that are being actively developed to
> eventually move into the backend, like autovacuum or slony-I should be in
> contrib. Things that aren't destined for backend integration should be
> removed though, like pgbench o
On Wed, 21 Apr 2004, Tom Lane wrote:
> No, those guys are exactly the sort of backend-dependent code I'm
> thinking of. Teodor just recently made a GIST API change that affected
> both the core backend and tsearch (as well as the other GIST modules in
> contrib). With separate distribution trees
People:
> I almost agree, but I think things that are being actively developed to
> eventually move into the backend, like autovacuum or slony-I should be in
> contrib. Things that aren't destined for backend integration should be
> removed though, like pgbench or dblink or whatnot.
I agree w
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Wed, 21 Apr 2004, Tom Lane wrote:
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> My personal opinion is that contrib should be removed entirely.
>>
>> That's not real workable for code that is tightly tied to the backend,
>> such as the var
> -Original Message-
> From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
> Sent: 21 April 2004 19:16
> To: Jan Wieck
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] contrib vs. gborg/pgfoundry for
> replication solutions
>
> Hello,
>
> My personal opinion is that contrib should b
IMHO it's not all that important where the source is developed (core
cvs, gborg etc) - whichever suits the development/release model best
shuold be used (meaning inside core only if it should be released on the
very same schedule as the main backend only).
What is more important is the exposure
Hello,
Well perhaps we can have exceptions. TSearch would be a good exception
as it really should be integrated into PostgreSQL anyway.
There are very few of these that I think would be an issue.
Sincerely,
Joshua D. Drake
Oleg Bartunov wrote:
The problem with moving all contribs to gborg is t
The problem with moving all contribs to gborg is that sometimes it's
required to change many modules, for example, because of changing
GiST interface. Tom saves a lot of working for contrib authors, when he
change code in core. I'm not sure, gborg would provide easy access for
such kind of things.
I almost agree, but I think things that are being actively developed to
eventually move into the backend, like autovacuum or slony-I should be in
contrib. Things that aren't destined for backend integration should be
removed though, like pgbench or dblink or whatnot.
On Wed, 21 Apr 2004, Joshu
Joe Conway wrote:
Jan Wieck wrote:
Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to
tsearch, I believe, is maintained somewhere else already, no? same with
tsearch2?
Yes that is correct but I think they commit back to contrib before they
release.
Realistically, although I did not used to agree, I believe that the only
that that should come with PostgreSQL is PostgreSQL and re
On Wed, 21 Apr 2004, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > My personal opinion is that contrib should be removed entirely.
>
> That's not real workable for code that is tightly tied to the backend,
> such as the various GIST index extensions presently in contrib. It'
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> My personal opinion is that contrib should be removed entirely.
That's not real workable for code that is tightly tied to the backend,
such as the various GIST index extensions presently in contrib. It's
just easier to maintain that code when it's i
Joshua D. Drake wrote:
Hello,
My personal opinion is that contrib should be removed entirely. Just
have a contrib.txt that says all contrib modules are at pgfoundry or
whatever.
I'm not so sure that's a good idea. I think contrib is a good
repository for code that is tightly tied to the bac
Valgrind'ing the postmaster yields a fair number of errors. A lot of
them are similar, such as the following:
==29929== Use of uninitialised value of size 4
==29929==at 0x80AFB80: XLogInsert (xlog.c:570)
==29929==by 0x808B0A6: heap_insert (heapam.c:1189)
==29929==by 0x808B19D: simple_h
Jan Wieck wrote:
> Taking into account that quite a few people have repeatedly stated that
> the components in contrib are considered more supported/recommended than
> similar solutions found on gborg or any other external site, I suggest
> we move the projects dbmirror and dblink to gborg. The
Hello,
My personal opinion is that contrib should be removed entirely. Just
have a contrib.txt that says all contrib modules are at pgfoundry or
whatever.
Sincerely,
Joshua D. Drake
Jan Wieck wrote:
Taking into account that quite a few people have repeatedly stated that
the components in co
Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module see
Hi,
I've made some very encouraging tests using The GNU version of Java known as
GCJ together with my Pl/Java implementation . At present I use GCJ just like
any other JVM, i.e. as an interpreter. This is not very optimal since GCJ
can compile all Java code into shared libraries just like it would
On Wednesday 21 April 2004 12:05 am, Christopher Kings-Lynne wrote:
> >> No, I have not heard of a 7.4.3 timeline, but we certainly want your
> >> eventual fixes in that release.
> >
> > Right, and along these lines there are a few other pg_autovacuum bugs
> > that were fixed just after 7.4.2.
>
>
> > CREATE RULE PasTouche AS ON UPDATE TO foo
> > WHERE old.locked=TRUE
> > DO INSTEAD ERROR;
>
> This would be sensible if rules were actually reasonable substitutes for
> triggers, but they are not.
>
> If you check the archives you will find many many cases where people
> tried t
50 matches
Mail list logo
