Re: unsubscribe

Hi!

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

Masi

Same here......

> Hi!
>
> I am getting mails from this list <pgsql-general(at)postgresql(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

On Tuesday 28 January 2003 09:38, you wrote:
> I am getting mails from this list <pgsql-general(at)postgresql(dot)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(at)preciso(dot)net
http://www.preciso.net

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

And you are not alone ;-)

--
Marius Žalinauskas

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(at)postgresql(dot)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

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

> Same here......
>
>
> > Hi!
> >
> > I am getting mails from this list <pgsql-general(at)postgresql(dot)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(at)postgresql(dot)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

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(at)persistent(dot)co(dot)in
Phone:- +91-20-5678900 Extn.270
Fax :- +91-20-5678901
-----------------------------------------------------------

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

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

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';

-----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-----

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

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

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(at)postgresql(dot)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(at)postgresql(dot)org
>

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 ...

Please unsubscribe me.

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

Unsubscribe me thanx

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(at)postgresql(dot)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(at)preciso(dot)net
> http://www.preciso.net
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

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.

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 ...

unsubscribe

Please unsubscribe me too.

--
%HAV-A-NICEDAY email mailto:steve(at)zeropps(dot)uklinux(dot)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

unsubscribe

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

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(dot)pipan(at)siol(dot)net>
To: <pgsql-general(at)postgresql(dot)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
>

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

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

Joe Conway <mail(at)joeconway(dot)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

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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(at)sysexperts(dot)com

Is there any TODO's here?

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

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> > 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