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
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
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
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
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-
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
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
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:
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
[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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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 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
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 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:
> 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 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 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 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
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
34 matches
Mail list logo
