On Mon, Dec 06, 2004 at 02:16:19AM -0500, [EMAIL PROTECTED] wrote:
> On Sun, 5 Dec 2004, Michael Fuhr wrote:
>
> > 1. Add -I$POSTGRES_HOME/include/server to Makefile.PL. Otherwise the
> > build fails with:
>
> On second thought: Apparently that if I do 'make install-all-headers' I
> would get th
On Mon, Dec 06, 2004 at 02:10:07AM -0500, [EMAIL PROTECTED] wrote:
> On Sun, 5 Dec 2004, Michael Fuhr wrote:
> > Why should the module need the PostgreSQL source code? It builds
> > fine using the headers under the PostgreSQL install directory (e.g.,
> > /usr/local/pgsql/include), at least with 8
On Sun, 5 Dec 2004, Michael Fuhr wrote:
> 1. Add -I$POSTGRES_HOME/include/server to Makefile.PL. Otherwise the
> build fails with:
On second thought: Apparently that if I do 'make install-all-headers' I
would get the files I need in include/server. I didn't know this - make
install won't instal
On Sun, 5 Dec 2004, Michael Fuhr wrote:
> On Mon, Dec 06, 2004 at 01:38:27AM -0500, [EMAIL PROTECTED] wrote:
> > On Sun, 5 Dec 2004, Michael Fuhr wrote:
> >
> > > Using PostgreSQL 8.0.0rc1 and Perl 5.8.6 on FreeBSD 4.10-STABLE and
> > > Solaris 9, I had to make a couple of changes to get DBD::PgS
On Mon, Dec 06, 2004 at 01:38:27AM -0500, [EMAIL PROTECTED] wrote:
> On Sun, 5 Dec 2004, Michael Fuhr wrote:
>
> > Using PostgreSQL 8.0.0rc1 and Perl 5.8.6 on FreeBSD 4.10-STABLE and
> > Solaris 9, I had to make a couple of changes to get DBD::PgSPI to
> > build:
> >
> > 1. Add -I$POSTGRES_HOME/i
On Sun, 5 Dec 2004, Michael Fuhr wrote:
> Using PostgreSQL 8.0.0rc1 and Perl 5.8.6 on FreeBSD 4.10-STABLE and
> Solaris 9, I had to make a couple of changes to get DBD::PgSPI to
> build:
>
> 1. Add -I$POSTGRES_HOME/include/server to Makefile.PL. Otherwise
> the build fails with:
You should point
On Mon, Dec 06, 2004 at 12:27:18AM -0500, [EMAIL PROTECTED] wrote:
> A short note that I've updated DBD::PgSPI version 0.02 to CPAN.
>
> There are no new features - but the code now expects (and works with)
> reasonably decent versions of perl (5.8.x) and pgsql (8.x).
Using PostgreSQL 8.0.0rc1
Hi,
I am using postgresql-7.4.5. I nee to use the jdbc connection So i
downloaded 4 versions of driver( pg74.215.jdbc1.jar,
pg74.215.jdbc2.jar, pg74.215.jdbc2ee.jar, pg74.215.jdbc3.jar). I am
uanble to connect it. Please let me know which version of driver i
have to use for postgresql-7.4.5 ?
On Sun, Dec 05, 2004 at 03:15:33PM -0500, Tom Lane wrote:
> It looks like someone #ifdef'd out those sections after observing that
> the PLy_result_methods table isn't used anyplace. Perhaps the place
> where it should have been used got lost in some earlier patch?
I think the #ifdef's happened
Hello,
A short note that I've updated DBD::PgSPI version 0.02 to CPAN.
There are no new features - but the code now expects (and works with)
reasonably decent versions of perl (5.8.x) and pgsql (8.x).
No warranty is given, this code compiles and 'scratches my itch'. If it
happens to scratch y
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Use two tables. One has rules, the other has the trigger. (Neither store
> any data.) Here's a working example (tested on 7.4.5):
> -- declare the table which we're going to be manipulating. This never
> -- actually stores anything (it becomes a vie
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Peter has dealt with all the translation encodings for a long time.
> > It would be good for someone who understands encodings to take
> > ownership of the encoding patches.
>
> I would have dealt with this patch if someone had submitted a patch
Bruce Momjian wrote:
> Peter has dealt with all the translation encodings for a long time.
> It would be good for someone who understands encodings to take
> ownership of the encoding patches.
I would have dealt with this patch if someone had submitted a patch as I
had requested.
--
Peter Eise
On Sun, 5 Dec 2004, Andrew Dunstan wrote:
As for suggestions, elsewhere you wrote:
"Now, if I don't understand the patch, we can change the procedure so I
require someone to state it is OK rather than the fallback of quiet
acceptance, especially just before a beta or RC version."
I believe that thi
On 2004-12-05, elein <[EMAIL PROTECTED]> wrote:
> We're working on DBI-link which is an access method of sorts
> using existing tools.
>
> We want an empty local table foo with
> 1. a _RETURN RULE
> 2. an update TRIGGER
> 3. a delete TRIGGER
> 4. an insert TRIGGER
Use two t
We'd want the tuples to be produced by the select rule
and treated as if we didn't care where they came from.
Perhaps it doesn't work this way because of the way srfs
were integrated into the SQL execution? I dunno.
do instead triggers should be deemed safe on a view
for those brave enough to try
Andrew Dunstan wrote:
> I'm sorry if I offended you.
>
> As for suggestions, elsewhere you wrote:
>
> "Now, if I don't understand the patch, we can change the procedure so I
> require someone to state it is OK rather than the fallback of quiet
> acceptance, especially just before a beta or RC ver
Bruce Momjian wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
I think it would be reasonable to insist on
at least one concurrence ("looks ok to me") posted to pgsql-patches
before applying during late beta. We've gotten into a mode where
if you like a patch you say nothing, but I wonder whe
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Now, if I don't understand the patch, we can change the procedure so I
> > require someone to state it is OK rather than the fallback of quiet
> > acceptance, especially just before a beta or RC version.
>
> I am not suggesting that w
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Now, if I don't understand the patch, we can change the procedure so I
> require someone to state it is OK rather than the fallback of quiet
> acceptance, especially just before a beta or RC version.
I am not suggesting that we need to tighten up during
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >I think it would be reasonable to insist on
> >at least one concurrence ("looks ok to me") posted to pgsql-patches
> >before applying during late beta. We've gotten into a mode where
> >if you like a patch you say nothing, but I wonder whether we
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Marc G. Fournier wrote:
> >> On Sat, 4 Dec 2004, Bruce Momjian wrote:
> >>> OK, so what do we want the process to be?
> >>
> >> Basically, during Beta/Release, we should almost a policy where a third
> >> party patch needs to be appr
elein <[EMAIL PROTECTED]> writes:
> Also, what are the reasons for forbidding triggers on views?
The fact that they'd never fire (or better never fire). A view does not
actually store any tuples, so update and delete triggers on it are
certainly useless. You could imagine allowing BEFORE INSERT
[EMAIL PROTECTED] writes:
> template2=# CREATE TABLE base (i integer);
> template2=# CREATE TABLE derived () INHERITS (base);
> template2=# INSERT INTO derived (i) VALUES (0);
> template2=# SELECT derived::base FROM derived;
> TRAP: FailedAssertion
The cause of this failure is that parse_coerce.c
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Yes, some kind of information "initdb required because column xxx was
dropped" would be helpful. When scanning the whole beta4-to-beta5 file,
you'd easily miss the consequence of the 2004-11-05 patch ("remove
concept of a schema having an
We're working on DBI-link which is an access method of sorts
using existing tools.
We want an empty local table foo with
1. a _RETURN RULE
2. an update TRIGGER
3. a delete TRIGGER
4. an insert TRIGGER
It seems we can have either the RULE or the TRIGGERs but not bot
On Sun, Dec 05, 2004 at 08:21:36PM +0100, Thomas Hallgren wrote:
> I'm in process of releasing a PL/Java based on the latest 8.0.0rc1. My
> Linux box is x86_64 based and even if I can cross-compile a 32 bit
> binary on it, I feel it's not really the same thing. Normally I use the
> "testdrive" o
Tom Lane wrote:
I think it would be reasonable to insist on
at least one concurrence ("looks ok to me") posted to pgsql-patches
before applying during late beta. We've gotten into a mode where
if you like a patch you say nothing, but I wonder whether we shouldn't
change that habit.
Amen, broth
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Marc G. Fournier wrote:
>> On Sat, 4 Dec 2004, Bruce Momjian wrote:
>>> OK, so what do we want the process to be?
>>
>> Basically, during Beta/Release, we should almost a policy where a third
>> party patch needs to be approved by a second committer *be
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Any comments on this? The 8.0.0rc1 PL/Python documentation,
> Section 39.3 "Database Access", still mentions the nrows and
> status methods, but they don't work. Here's Oliver's original
> message and my followup:
> http://archives.postgresql.org/pgsql-
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Yes, some kind of information "initdb required because column xxx was
> dropped" would be helpful. When scanning the whole beta4-to-beta5 file,
> you'd easily miss the consequence of the 2004-11-05 patch ("remove
> concept of a schema having an associa
I'm in process of releasing a PL/Java based on the latest 8.0.0rc1. My
Linux box is x86_64 based and even if I can cross-compile a 32 bit
binary on it, I feel it's not really the same thing. Normally I use the
"testdrive" over at hp but it has had a "no space left on device" status
for a couple
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, good summary. Shame we missed this for 8.0. I am sure we will do
> better next time.. Wow, you had been working on this since November
> 2nd. Shame it didn't make it. Sorry again.
A minimum requirement for accepting an updated patch is that it s
Robert Treat wrote:
On Monday 29 November 2004 23:52, Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
don't we normally announce if initdb is required on new beta releases? We
should.
It was sloppy that we didn't do that for beta5, and I apologize for it.
One problem is that we don't have
34 matches
Mail list logo
