Horton

Thread

  1. list server problems?

    Martin Kutschker <martin.kutschker@blackbox.net> — 2003-01-28T08:38:32Z

    Hi!

I am getting mails from this list <pgsql-general@postgresql.org> although - AFAIR :-) - I do not have subscribed.

Masi

  2. Re: list server problems?

    Gizmo <gizmo@thegremlins.net> — 2003-01-28T08:40:48Z

    Same here......


> Hi!
>
> I am getting mails from this list <pgsql-general@postgresql.org>
although - AFAIR :-) - I do not have subscribed.
>
> Masi
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

  3. Re: list server problems?

    gianpaolo racca <gianpaolo@preciso.net> — 2003-01-28T08:45:35Z

    On Tuesday 28 January 2003 09:38, you wrote:
> I am getting mails from this list <pgsql-general@postgresql.org> although -
> AFAIR :-) - I do not have subscribed.

me too...

-- 
Il male non cresce mai così bene come quando ha
un ideale davanti a sè (Karl Kraus)
-----------------------------------------------------------------
gianpaolo racca
gianpaolo@preciso.net
http://www.preciso.net

  4. Re: list server problems?

    Marius Žalinauskas <mariusz@delfi.lt> — 2003-01-28T08:50:48Z

    2003 m. Sausio 28 d., Antradienis 10:38:
> Hi!
>
> I am getting mails from this list <pgsql-general@postgresql.org> although -
> AFAIR :-) - I do not have subscribed.

And you are not alone ;-)

-- 
Marius Žalinauskas

  5. Re: list server problems?

    Daryl Tester <daryl.tester@iocane.com.au> — 2003-01-28T09:16:55Z

    I subscribed once or twice, over 6 months ago, but never received
any mail from the list (until now).  Maybe someone's fixed what
was broken?

Gizmo wrote:
> 
> Same here......
> 
> > Hi!
> >
> > I am getting mails from this list <pgsql-general@postgresql.org>
> although - AFAIR :-) - I do not have subscribed.
> >
> > Masi



-- 
Regards,
  Daryl Tester,  Software Wrangler and Bit Herder, IOCANE Pty. Ltd.

"Um ... those are IP addresses the quarterback guy yells out, right?"
"No, A.J. ... they're wild guesses at your I.Q." --  User Friendly

  6. Re: list server problems?

    Travis Bauer <trbauer@indiana.edu> — 2003-01-28T10:13:55Z

    Same here.  Looks like someone mass subscribed us.
Gizmo (gizmo@thegremlins.net) wrote:

> Same here......
> 
> 
> > Hi!
> >
> > I am getting mails from this list <pgsql-general@postgresql.org>
> although - AFAIR :-) - I do not have subscribed.
> >
> > Masi
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
> >
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html

  7. Re: list server problems?

    Shridhar Daithankar <shridhar_daithankar@persistent.co.in> — 2003-01-28T10:30:31Z

    On 28 Jan 2003 at 5:13, Travis Bauer wrote:

> Same here.  Looks like someone mass subscribed us.

Or mass initialized the general list with already known pg guys..;-)

Regards,
 Shridhar

-----------------------------------------------------------
Shridhar Daithankar
LIMS CPE Team Member, PSPL.
mailto:shridhar_daithankar@persistent.co.in
Phone:- +91-20-5678900 Extn.270
Fax  :- +91-20-5678901 
-----------------------------------------------------------

  8. Re: list server problems?

    Gordan Bobic <gordan@bobich.net> — 2003-01-28T11:32:57Z

    On Tue, 28 Jan 2003, Shridhar Daithankar wrote:

> On 28 Jan 2003 at 5:13, Travis Bauer wrote:
> 
> > Same here.  Looks like someone mass subscribed us.
> 
> Or mass initialized the general list with already known pg guys..;-)

Are the efforts in progress to unsubscribe those of us who shouldn't be 
subscribed?

Regards.

Gordan

  9. Re: list server problems?

    Ron <theotiwii@earthlink.net> — 2003-01-28T13:19:55Z

    Daryl Tester wrote:

> I subscribed once or twice, over 6 months ago

A fine time for a "ME TOO!" I subscribed lonnnnnggg ago, wrote the list
manager OVER and OVER about not receiving list messages...NEVER a
response... 

I switched to MySQL... :-/

-Ron

  10. problems with dropped columns

    Damjan Pipan <damjan.pipan@siol.net> — 2003-01-28T13:36:25Z

    Hi!

I have following problem:
I have created a table with some fields, then I dropped last field (integer)
and added
one extra field (integer). Then I have created a function which returns
record of table
type. I have selected a record from table and returned it, but the values in
last
field are wrong (missing). It looks like that it takes the dropped field
instead of the last field.

Damjan

CREATE OR REPLACE FUNCTION damjan_test111(integer) RETURNS public.fk_test AS
'
DECLARE
rec fk_test%ROWTYPE;
siteid ALIAS FOR $1;
BEGIN
FOR rec IN SELECT * FROM public.fk_test WHERE
i = siteid LOOP
RETURN rec;
END LOOP;
END;
' LANGUAGE 'plpgsql';

  11. Re: list server problems?

    William WAISSE <wwaisse@neofutur.net> — 2003-01-28T14:07:19Z

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > I subscribed once or twice, over 6 months ago
 the same for me.
 Subscribed posted and unsubscribed long ago too.

 I have not subscribed again .

 Should I unsubscribe again myself ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+No6X33a3jGkLTgcRAqnSAJsEPr3jyz3unPs6QQg/Niw2xbs5wQCgjbH2
gyzWAAc93l5k6UEGkbixPQ4=
=oA5P
-----END PGP SIGNATURE-----

  12. Re: list server problems?

    tony <tony@tgds.net> — 2003-01-28T15:46:36Z

    IT'S FIXED!!!!!!!!!!!!!!!!!

Now that was a shock...

Tony Grant

-- 
www.tgds.net Library management software toolkit, 
redhat linux on Sony Vaio C1XD, 
Dreamweaver MX with Tomcat and PostgreSQL

  13. Re: list server problems?

    Tomaz Borstnar <tomaz.borstnar@over.net> — 2003-01-28T16:33:49Z

    At 05:19 28.1.2003 -0800, Ron wrote the following message:
>A fine time for a "ME TOO!" I subscribed lonnnnnggg ago, wrote the list
>manager OVER and OVER about not receiving list messages...
I had problems only with general lists, other lists were working fine. I 
used newsgroup during this time and Elen's summaries.


>NEVER a
>response...
Well, all these people have other work to do as well. We should respect that.


>I switched to MySQL... :-/
Just because of that? Pity. Pgsql is very nice database which needs some 
quality time from its users to perform even  better.


Tomaz

  14. Re: list server problems?

    Marc G. Fournier <scrappy@hub.org> — 2003-01-28T18:03:33Z

    I shut everything down last night and rebuilt the subscriber database for
pgsql-general (it was corrupted) ... apologies to those that may have
unsubscribed at some point, and are now re-subscribed ... the rebuild
process doesn't seem to know how to deal with that too well yet ...




On Tue, 28 Jan 2003, Daryl Tester wrote:

> I subscribed once or twice, over 6 months ago, but never received
> any mail from the list (until now).  Maybe someone's fixed what
> was broken?
>
> Gizmo wrote:
> >
> > Same here......
> >
> > > Hi!
> > >
> > > I am getting mails from this list <pgsql-general@postgresql.org>
> > although - AFAIR :-) - I do not have subscribed.
> > >
> > > Masi
>
>
>
> --
> Regards,
>   Daryl Tester,  Software Wrangler and Bit Herder, IOCANE Pty. Ltd.
>
> "Um ... those are IP addresses the quarterback guy yells out, right?"
> "No, A.J. ... they're wild guesses at your I.Q." --  User Friendly
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>

  15. Re: list server problems?

    Marc G. Fournier <scrappy@hub.org> — 2003-01-28T18:04:52Z

    On Tue, 28 Jan 2003, Gordan Bobic wrote:

> On Tue, 28 Jan 2003, Shridhar Daithankar wrote:
>
> > On 28 Jan 2003 at 5:13, Travis Bauer wrote:
> >
> > > Same here.  Looks like someone mass subscribed us.
> >
> > Or mass initialized the general list with already known pg guys..;-)
>
> Are the efforts in progress to unsubscribe those of us who shouldn't be
> subscribed?

No, as we don't know who shouldn't be subscribeed ... plesae send in an
unsubscribe request to get back off the list ...

  16. unsubscribe

    Zac Hillier <zac@affectors.net> — 2003-01-28T19:29:04Z

    Please unsubscribe me.

  17. Re: list server problems?

    Gordan Bobic <gordan@bobich.net> — 2003-01-28T22:12:15Z

    Sorry, but one of the replies I got implies that I need a password to 
unsubscribe. I don't have it any more. Can you please remove me off the list?

Thanks.

Gordan

  18. unsubscribe

    Kris Allsop <krisallsop@btinternet.com> — 2003-01-28T23:56:09Z

    Unsubscribe me thanx

  19. Re: list server problems?

    Shanmugasundaram Doraisamy <shan@ceedees.com> — 2003-01-29T11:21:26Z

    Dear Administrator/Moderator,
				I had subscribed to this group and I need only the digest version. 
But I am getting every post to this group as an individual mail.  I
understand there was some problem with this earlier.  Has it been
solved?  What should I do to get only the digest version.  Thanking you,

Yours sincerely,

D.Shanmugasundaram.


On Tue, 2003-01-28 at 14:15, gianpaolo racca wrote:
> On Tuesday 28 January 2003 09:38, you wrote:
> > I am getting mails from this list <pgsql-general@postgresql.org> although -
> > AFAIR :-) - I do not have subscribed.
> 
> me too...
> 
> -- 
> Il male non cresce mai così bene come quando ha
> un ideale davanti a sè (Karl Kraus)
> -----------------------------------------------------------------
> gianpaolo racca
> gianpaolo@preciso.net
> http://www.preciso.net
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org

  20. Re: list server problems?

    Francisco J Reyes <fran@natserv.net> — 2003-01-29T15:20:07Z

    On Tue, 28 Jan 2003, Marc G. Fournier wrote:

> No, as we don't know who shouldn't be subscribeed ... plesae send in an
> unsubscribe request to get back off the list ...


Was/is there a simmilar problem with ther performance list? Several months
back when the announcement was sent about the performance list I tried
several times to subscribe, but never got a notification.

  21. Re: list server problems?

    Marc G. Fournier <scrappy@hub.org> — 2003-01-29T17:24:44Z

    On Wed, 29 Jan 2003, Francisco J Reyes wrote:

> On Tue, 28 Jan 2003, Marc G. Fournier wrote:
>
> > No, as we don't know who shouldn't be subscribeed ... plesae send in an
> > unsubscribe request to get back off the list ...
>
>
> Was/is there a simmilar problem with ther performance list? Several months
> back when the announcement was sent about the performance list I tried
> several times to subscribe, but never got a notification.

There might have been, but right now a verification of all databases comes
up with no error (please note, this is not a PgSQL database backend,
Majordomo2 uses a DB3 backend) ... you migth try again and see, as I know
the list itself is fairely active ...

  22. unsubscribe

    Gordon A. Campbell <gordie@columbia.edu> — 2003-01-29T18:01:53Z

    unsubscribe

  23. Re: unsubscribe

    steve <steve@zeropps.uklinux.net> — 2003-01-30T01:24:55Z

    Please unsubscribe me too. 

-- 
%HAV-A-NICEDAY                    email mailto:steve@zeropps.uklinux.net
Steve                                web http://www.zeropps.uklinux.net/
                                             or http://start.at/zero-pps
  1:24am  up 38 days,  1:44,  1 user,  load average: 1.00, 1.05, 1.18

  24. unsubscribe

    Terri Lerose <terri.lerose@att.net> — 2003-02-02T23:52:21Z

    unsubscribe

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

  25. Re: [GENERAL] problems with dropped columns

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2003-03-06T02:21:36Z

    I want to fix this bug, however I can't see how the example below is
failing...  (Obeys dropped columns)  I'm not up with my SRFs, so would
someone be able to post a concise SQL script that demonstrates the failure?

I can see in the code that it should be failing, but I need a demonstrated
example...

Chris


----- Original Message -----
From: "Damjan Pipan" <damjan.pipan@siol.net>
To: <pgsql-general@postgresql.org>
Sent: Tuesday, January 28, 2003 9:36 PM
Subject: [GENERAL] problems with dropped columns


> Hi!
>
> I have following problem:
> I have created a table with some fields, then I dropped last field
(integer)
> and added
> one extra field (integer). Then I have created a function which returns
> record of table
> type. I have selected a record from table and returned it, but the values
in
> last
> field are wrong (missing). It looks like that it takes the dropped field
> instead of the last field.
>
> Damjan
>
> CREATE OR REPLACE FUNCTION damjan_test111(integer) RETURNS public.fk_test
AS
> '
> DECLARE
> rec fk_test%ROWTYPE;
> siteid ALIAS FOR $1;
> BEGIN
> FOR rec IN SELECT * FROM public.fk_test WHERE
> i = siteid LOOP
> RETURN rec;
> END LOOP;
> END;
> ' LANGUAGE 'plpgsql';
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

  26. Re: [HACKERS] problems with dropped columns

    Joe Conway <mail@joeconway.com> — 2003-03-06T05:20:21Z

    Christopher Kings-Lynne wrote:
> I want to fix this bug, however I can't see how the example below is
> failing...  (Obeys dropped columns)  I'm not up with my SRFs, so would
> someone be able to post a concise SQL script that demonstrates the failure?
> 
> I can see in the code that it should be failing, but I need a demonstrated
> example...

Here is a self contained example using cvs tip:

CREATE TABLE fk_test (f1 int, f2 int);
insert into fk_test(f1, f2) values(1, 21);
insert into fk_test(f1, f2) values(2, 22);

ALTER TABLE fk_test DROP COLUMN f2;
ALTER TABLE fk_test ADD COLUMN f3 int;

insert into fk_test(f1, f3) values(3, 33);
insert into fk_test(f1, f3) values(4, 34);

regression=# select * from fk_test ;
  f1 | f3
----+----
   1 |
   2 |
   3 | 33
   4 | 34
(4 rows)

CREATE OR REPLACE FUNCTION test()
RETURNS SETOF fk_test AS '
   DECLARE
     rec fk_test%ROWTYPE;
   BEGIN
     FOR rec IN SELECT * FROM fk_test LOOP
       RETURN NEXT rec;
     END LOOP;
     RETURN;
   END;
' LANGUAGE 'plpgsql';

regression=# select * from test();
  f1 | f3
----+----
   1 |
   2 |
   3 |
   4 |
(4 rows)


Joe

  27. Re: [HACKERS] problems with dropped columns

    Joe Conway <mail@joeconway.com> — 2003-03-06T05:32:01Z

    Christopher Kings-Lynne wrote:
> I want to fix this bug, however I can't see how the example below is
> failing...  (Obeys dropped columns)  I'm not up with my SRFs, so would
> someone be able to post a concise SQL script that demonstrates the failure?
> 
> I can see in the code that it should be failing, but I need a demonstrated
> example...

Taking it a bit further...

CREATE TABLE fk_test (f1 int, f2 int);
insert into fk_test(f1, f2) values(1, 21);
insert into fk_test(f1, f2) values(2, 22);

ALTER TABLE fk_test DROP COLUMN f2;
ALTER TABLE fk_test ADD COLUMN f3 int;

insert into fk_test(f1, f3) values(3, 33);
insert into fk_test(f1, f3) values(4, 34);

CREATE OR REPLACE FUNCTION test()
RETURNS SETOF fk_test AS '
   DECLARE
     rec fk_test%ROWTYPE;
   BEGIN
     FOR rec IN SELECT * FROM fk_test LOOP
       RETURN NEXT rec;
     END LOOP;
     RETURN;
   END;
' LANGUAGE 'plpgsql';

regression=# select * from test();
  f1 | f3
----+----
   1 |
   2 |
   3 |
   4 |
(4 rows)

regression=# ALTER TABLE fk_test DROP COLUMN f3;
ALTER TABLE
regression=# select * from test();
  f1
----
   1
   2
   3
   4
(4 rows)

regression=# ALTER TABLE fk_test ADD COLUMN f3 int;
ALTER TABLE
regression=# select * from test();
WARNING:  Error occurred while executing PL/pgSQL function test
WARNING:  line 5 at return next
ERROR:  Wrong record type supplied in RETURN NEXT

CREATE OR REPLACE FUNCTION test()
RETURNS SETOF fk_test AS '
   DECLARE
     rec fk_test%ROWTYPE;
   BEGIN
     FOR rec IN SELECT * FROM fk_test LOOP
       RETURN NEXT rec;
     END LOOP;
     RETURN;
   END;
' LANGUAGE 'plpgsql';

regression=# select * from test();
  f1 | f3
----+----
   1 |
   2 |
   3 |
   4 |
(4 rows)

Joe

  28. Re: [HACKERS] problems with dropped columns

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-03-06T06:18:41Z

    Joe Conway <mail@joeconway.com> writes:
> Taking it a bit further...

There are (at least) two distinct problems involved here.  One is
getting plpgsql to deal correctly with rowtypes that include dropped
columns.  The other is getting it to react when someone alters a table
whose rowtype is relied on by already-compiled functions.

The former problem is just a small matter of programming in plpgsql;
I'm not sure what the best way to do it is, but it's clearly just
plpgsql's issue.  The latter problem calls for a ton of infrastructure
that we haven't got :-(

			regards, tom lane

  29. Re: [HACKERS] problems with dropped columns

    Kevin Brown <kevin@sysexperts.com> — 2003-03-06T21:52:47Z

    Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > Taking it a bit further...
> 
> There are (at least) two distinct problems involved here.  One is
> getting plpgsql to deal correctly with rowtypes that include dropped
> columns.  The other is getting it to react when someone alters a table
> whose rowtype is relied on by already-compiled functions.
> 
> The former problem is just a small matter of programming in plpgsql;
> I'm not sure what the best way to do it is, but it's clearly just
> plpgsql's issue.  The latter problem calls for a ton of infrastructure
> that we haven't got :-(

Hmm, well...

- Keeping timestamps of when the table definition was last changed and
  when the function was last compiled, and then having the language
  interpreter check the two before executing the function (and
  recompile it when the function is out of date) would solve the
  problem (and require relatively little additional infrastructure),
  but I would expect the performance hit to be too high to be worth
  it.

- Alternatively, the language compiler could record a dependency
  between the function and the table (assuming this isn't done
  already), and be told to recompile the function when the table
  definition changes.  This gets real messy when you're talking about
  doing this in a transaction, unless the compilation itself is
  something that can be rolled back (it wouldn't surprise me in the
  least if the compiled definition is stored in a table already and
  thus can be rolled back).

- Alternatively, recompilation could be made a manual thing,
  e.g. ALTER FUNCTION blah RECOMPILE.  It would still be a win for
  this to be transaction-capable.


-- 
Kevin Brown					      kevin@sysexperts.com

  30. Re: [HACKERS] problems with dropped columns

    Bruce Momjian <pgman@candle.pha.pa.us> — 2003-03-07T17:40:33Z

    Is there any TODO's here?

---------------------------------------------------------------------------

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > Taking it a bit further...
> 
> There are (at least) two distinct problems involved here.  One is
> getting plpgsql to deal correctly with rowtypes that include dropped
> columns.  The other is getting it to react when someone alters a table
> whose rowtype is relied on by already-compiled functions.
> 
> The former problem is just a small matter of programming in plpgsql;
> I'm not sure what the best way to do it is, but it's clearly just
> plpgsql's issue.  The latter problem calls for a ton of infrastructure
> that we haven't got :-(
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

  31. Re: [GENERAL] problems with dropped columns

    Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2003-03-08T04:09:01Z

    > > There are (at least) two distinct problems involved here.  One is
> > getting plpgsql to deal correctly with rowtypes that include dropped
> > columns.  The other is getting it to react when someone alters a table
> > whose rowtype is relied on by already-compiled functions.

I'm working on this one...I don't know all the dependencies of things off
the top of my head, so it's a little bit painstakign...

Chris