Re: [HACKERS] GRANT ON ALL IN schema
Hi, Le 10 août 09 à 17:19, Andrew Dunstan a écrit : One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo$ $ LANGUAGE plfoo; We could even default the langauge to plpgsql, for which you would then just need: DO $$ something in plpgsql $$; That would also be a nice feature to rely on in extensions install.sql files when you have major version dependant code. Defining a function, calling it then removing it is what to do now. This new syntax would greatly simplify the support code. DO $$ IF postgresql_major_version = '8.2' THEN ... ELSE ... END IF; $$; (of course in this snippet example the ELSE covers it because the CREATE EXTENSION stuff declared e.g. dependancy on postgresql = 8.2). Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
2009/8/15 Dimitri Fontaine dfonta...@hi-media.com: Hi, Le 10 août 09 à 17:19, Andrew Dunstan a écrit : One fairly simple way would use a new SQL verb (say, DO) like this: DO $$ something in plfoo$ $ LANGUAGE plfoo; We could even default the langauge to plpgsql, for which you would then just need: DO $$ something in plpgsql $$; That would also be a nice feature to rely on in extensions install.sql files when you have major version dependant code. Defining a function, calling it then removing it is what to do now. This new syntax would greatly simplify the support code. DO $$ IF postgresql_major_version = '8.2' THEN ... ELSE ... END IF; $$; why we need DO statement? Why not just $$ $$. Only string literal cannot be statement too, so DO is unnecessary. it can look like: $$ FOR r IN SELECT END LOOP; $$; ??? (of course in this snippet example the ELSE covers it because the CREATE EXTENSION stuff declared e.g. dependancy on postgresql = 8.2). Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Pavel Stehule wrote: why we need DO statement? Why not just $$ $$. Only string literal cannot be statement too, so DO is unnecessary. it can look like: $$ FOR r IN SELECT END LOOP; $$; ??? Well, it's arguably somewhat un-SQL-ish. Every command in SQL is introduced by a keyword verb. I'm also not sure I want to be trying to execute any arbitrary string that accidentally gets placed there because someone forgot to put a keyword or accidentally deleted it. But I'm not too dogmatic on the subject. What do others think? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
2009/8/15 Andrew Dunstan and...@dunslane.net: Pavel Stehule wrote: why we need DO statement? Why not just $$ $$. Only string literal cannot be statement too, so DO is unnecessary. it can look like: $$ FOR r IN SELECT END LOOP; $$; ??? Well, it's arguably somewhat un-SQL-ish. Every command in SQL is introduced by a keyword verb. sure - this is not SQL statement. I thing so most SQL-ish is T-SQL style. You have integrated procedural statements. so the best is directly: FOR LOOP END LOOP; but it's far future :) I'm also not sure I want to be trying to execute any arbitrary string that accidentally gets placed there because someone forgot to put a keyword or accidentally deleted it. But I'm not too dogmatic on the subject. What do others think? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Andrew Dunstan and...@dunslane.net writes: Pavel Stehule wrote: why we need DO statement? Why not just $$ $$. Only string literal cannot be statement too, so DO is unnecessary. I'm also not sure I want to be trying to execute any arbitrary string that accidentally gets placed there because someone forgot to put a keyword or accidentally deleted it. That's my feeling as well. Also, I don't think it is sane to allow options (like LANGUAGE foo) on a standalone string constant. Yeah, we could persuade bison to do it, but that doesn't make it a good idea. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] postgres-r
Hi, [ CC'ing to the postgres-r mailing list ] Mark Mielke wrote: On 08/12/2009 12:04 PM, Suno Ano wrote: can anybody tell me, is there a roadmap with regards to http://www.postgres-r.org ? I'm glad you're asking. I would love to see it become production-ready asap. Yes, me too. Do you have some spare cycles to spend? I'd be happy to help you getting started. However, I have a 16 days old daughter at home, so please don't expect response times under a few days ;-) Even a breakdown of what is left to do might be useful in case any of us want to pick at it. :-) The TODO file from the patch is a good place to start from. For the sake of simplicity, I've attached it. I've written a series of posts covering various topics of Postgres-R about a year ago. Here are the links, following the discussions down-thread might be interesting as well. Postgres-R: current state of development, Jul 15 2008: http://archives.postgresql.org/pgsql-hackers/2008-07/msg00735.php Postgres-R: primary key patches, Jul 16 2008 http://archives.postgresql.org/pgsql-hackers/2008-07/msg00777.php Postgres-R: tuple serialization, Jul 22 2008 http://archives.postgresql.org/pgsql-hackers/2008-07/msg00969.php Postgres-R: internal messaging, Jul 23 2008 http://archives.postgresql.org/pgsql-hackers/2008-07/msg01051.php Some random updates to last year's current state of development that come to mind: * I've adjusted to the signaling to use the signal multiplexer code that recently landed on HEAD. * Work on the initialization and recovery stuff is progressing slowly, but steadily. * The tuple serialization code is being refactored ATM to get a lot smaller and easier to understand and debug. That should get you an impression on the current state of development, I think. Please feel free to ask more specific questions. Regards Markus Wanner P.S.: Sanu, did you note the addition of the link to the Postgres-R mailing list, which you pointed out was hard to find? URGENT == * Implement parsing of the replication_gcs GUC for spread and ensemble. * check for places there replication_enabled should be checked more extensively. complaint about select() not interrupted by signals: http://archives.postgresql.org/pgsql-hackers/2008-12/msg00448.php restartable signals 'n all that http://archives.postgresql.org/pgsql-hackers/2007-07/msg3.php 3.2.1 Internal Message Passing == * Maybe send IMSGT_READY after some other commands, not only after IMSGT_CHANGESET. Remember that local transactions also have to send an IMSGT_READY, so that their proc-coid gets reset. * Make sure the coordinator copes with killed backends (local as well as remote ones). * Check if we can use pselect to avoid race conditions with IMessage stuff within the coordinator's main loop. * Check error conditions such as out of memory and out of disk space. Those could prevent a single node from applying a remote transaction. What to do in such cases? A similar one is limit of queued remote transactions reached. 3.2.2 Communication with the Postmaster === * Get rid of the SIGHUP signal (was IMSGT_SYSTEM_READY) for the coordinator and instead only start the coordinator as soon as the postmaster is ready to fork helper backends. Should simplify things and make them more similar to the current Postgres code, i.e. for the autovacuum launcher. * Handle restarts of the coordinator due to a crashed backend. The postmaster already sends a signal to terminate an existing coordinator process and it tries to restart one. But the coordinator should then start recovery and only allow other backends after that. Keep in mind that this recovery process is costly and we should somehow prevent nodes which fail repeatedly from endlessly consuming resources of the complete cluster. * The backends need to report errors from remote *and* local transactions to the coordinator. Worker backends erroring out while waitin for changesets are critical. Erroring out due to serialization failure is fine, we can simply ignore the changeset, once it arrives late on. But other errors are probably pretty bad at that stage. Upon crashes, the postmaster restarts all backends and the coordinator anyway, so the backend process itself can take care of informing the coordinator via imessages. * Think about a newly requested helper backend crashing before it registers with the coordinator. That would prevent requesting any further helper backend. 3.2.3 Group Communication System Issues === * Drop the static receive buffers of the GCS interfaces in favor of a dynamic one. It's much easier to handle. * Hot swapping of the underlying GCS of a replicated database is currently not supported. It would involve waiting for all nodes of the group to have joined the new group, then swap. If we enforce the GCS group name to
Re: [HACKERS] uuid contrib don't compile in OpenSolaris
problem is that PostgreSQL uses ossp UUID which is not integrated in OpenSolaris. Solaris has own uuid implementation which seems to me similar but not same. Try man uuid_generate or less /usr/uuid/uuid.h That's really interesting. I'll try this. It should be easy to port it but it needs a time :(. Zdenek I found that the same problem cames from 8.3.4 http://archives.postgresql.org/pgsql-general/2008-10/msg01234.php But i found too, that seems to be a bug in x86 platforms for uuid_generator. I tryed to run uuidgen, but throws a lib.so.1 absence. Seems that the problem comes more dephtly. -- Emanuel Calvo Franco Database consultant at: www.siu.edu.ar www.emanuelcalvofranco.com.ar -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Why we have tuplestore and tuplesort?
Thinking about window function performance improvement as well as concerning about GROUPING SETS discussed a couple of days before, I wonder why we have both of tuplestore and tuplesort. They are very similar but have different functions such as multiple read pointer with tuplestore whereas perform_sort with tuplesort. If we integrate them, nodeWindowAgg, for instance, won't need Sort node before it and will be able to avoid redundant tuple copy from the tuplesort (on the Sort node) to the tuplestore. Looking for git/cvs log a bit, tuplesort was already there since 1999 while tuplestore was introduced around 2000 for materialized node. Why then was tuplestore invented as a new feature instead of extending tuplesort? Can't we unit them now? Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why we have tuplestore and tuplesort?
Hitoshi Harada umi.tan...@gmail.com writes: Looking for git/cvs log a bit, tuplesort was already there since 1999 while tuplestore was introduced around 2000 for materialized node. Why then was tuplestore invented as a new feature instead of extending tuplesort? Can't we unit them now? I think they'd be unmaintainable if merged. Each one is complicated enough as-is, and they have different concerns and different use-cases to optimize for. Moreover it's not clear that merging them would buy us much --- saving one copy step doesn't excite me, even if it actually came out to be true which I'm unconvinced about. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why we have tuplestore and tuplesort?
2009/8/16 Tom Lane t...@sss.pgh.pa.us: Hitoshi Harada umi.tan...@gmail.com writes: Looking for git/cvs log a bit, tuplesort was already there since 1999 while tuplestore was introduced around 2000 for materialized node. Why then was tuplestore invented as a new feature instead of extending tuplesort? Can't we unit them now? I think they'd be unmaintainable if merged. Each one is complicated enough as-is, and they have different concerns and different use-cases to optimize for. Moreover it's not clear that merging them would buy us much --- saving one copy step doesn't excite me, even if it actually came out to be true which I'm unconvinced about. regards, tom lane I agree it would be unmaintainable. However it sounds like there's no crystal clear reason the two are separated. Before tuplestore got multiple read pointers it was quite similar to tuplestore except performing sort so I can imagine allowing tuplesort to have multiple read pointers. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
I'm also not sure I want to be trying to execute any arbitrary string
that accidentally gets placed there because someone forgot to put a
keyword or accidentally deleted it.
But I'm not too dogmatic on the subject. What do others think?
Given that $$ is also used to quote non-procedural strings, I don't like
the idea that psql would be trying to execute any string I gave it after
forgetting select. If nothing else, that would lead to confusing and
misleading error messages.
Ideally, we'd be able to execute *any* PL that way by setting a shell
variable:
\pl plperl
DO $f$ foreach ( @_ ) { ...
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why we have tuplestore and tuplesort?
2009/8/16 Hitoshi Harada umi.tan...@gmail.com: 2009/8/16 Tom Lane t...@sss.pgh.pa.us: Hitoshi Harada umi.tan...@gmail.com writes: Looking for git/cvs log a bit, tuplesort was already there since 1999 while tuplestore was introduced around 2000 for materialized node. Why then was tuplestore invented as a new feature instead of extending tuplesort? Can't we unit them now? I think they'd be unmaintainable if merged. Each one is complicated enough as-is, and they have different concerns and different use-cases to optimize for. Moreover it's not clear that merging them would buy us much --- saving one copy step doesn't excite me, even if it actually came out to be true which I'm unconvinced about. regards, tom lane I agree it would be unmaintainable. However it sounds like there's no crystal clear reason the two are separated. Before tuplestore got multiple read pointers it was quite similar to tuplestore except oops, similar to tuplesort performing sort so I can imagine allowing tuplesort to have multiple read pointers. Regards, -- Hitoshi Harada -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Le 15 août 09 à 22:49, Josh Berkus a écrit :
Ideally, we'd be able to execute *any* PL that way by setting a shell
variable:
\pl plperl
DO $f$ foreach ( @_ ) { ...
Nitpicking dept, I think I prefer:
DO [ [LANGUAGE] language] $$ ... $$;
DO plperl $$ ... $$;
DO language plpython $$ ... $$;
language is optional and defaults to plpgsql.
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
On Sat, Aug 15, 2009 at 11:34:04PM +0200, Dimitri Fontaine wrote: Nitpicking dept, I think I prefer: DO [ [LANGUAGE] language] $$ ... $$; DO plperl $$ ... $$; DO language plpython $$ ... $$; language is optional and defaults to plpgsql. Yup, sounds nicer. The less globals the better! Next all you need is to be able to PREPARE them (and somehow access the parameters from execute) and you'll have nice local functions. :) -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Josh Berkus wrote:
I'm also not sure I want to be trying to execute any arbitrary string
that accidentally gets placed there because someone forgot to put a
keyword or accidentally deleted it.
But I'm not too dogmatic on the subject. What do others think?
Given that $$ is also used to quote non-procedural strings, I don't like
the idea that psql would be trying to execute any string I gave it after
forgetting select. If nothing else, that would lead to confusing and
misleading error messages.
Ideally, we'd be able to execute *any* PL that way by setting a shell
variable:
\pl plperl
DO $f$ foreach ( @_ ) { ...
I think you have misunderstood.
I am not talking at all about doing this in psql. It would be built into
the server's SQL so you could use any client, and the default language
would be a GUC as Tom suggested upstream.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
On fre, 2009-08-14 at 13:57 -0700, Jeff Davis wrote: Looking at the definitions of vacuum_freeze_min_age and autovacuum_freeze_max_age there seems to be almost no distinction between min and max in those two names. For min, the action happens at or above the min values. For max, the action happens at or below the max value. With those two particular parameters, the freezing happens exactly between the min and the max value. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Remove tabs from SGML.
Bruce Momjian wrote: Log Message: --- Remove tabs from SGML. Tags: REL8_3_STABLE Modified Files: -- pgsql/doc/src/sgml/ref: psql-ref.sgml (r1.198.2.1 - r1.198.2.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/psql-ref.sgml?r1=1.198.2.1r2=1.198.2.2) Do we have some recommended emacs settings for editing the docs? Do we need a pgsql-docs mode? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
On lör, 2009-08-15 at 23:31 +0100, Sam Mason wrote: On Sat, Aug 15, 2009 at 11:34:04PM +0200, Dimitri Fontaine wrote: Nitpicking dept, I think I prefer: DO [ [LANGUAGE] language] $$ ... $$; DO plperl $$ ... $$; DO language plpython $$ ... $$; language is optional and defaults to plpgsql. Yup, sounds nicer. The less globals the better! Next all you need is to be able to PREPARE them (and somehow access the parameters from execute) and you'll have nice local functions. :) Yeah, rather than just making up some new command for execute this string, this could be generalized as lambda expressions that could be called whereever an expression is allowed. E.g. SELECT LAMBDA $$ ... $$; -- if CALL is implemented CALL LAMBDA $$ ... $$; PREPARE foo AS SELECT LAMBDA $$ ... $$; EXECUTE foo; SELECT (LAMBDA (x int, y text) $$ ... $$) (37, 'foo'); -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Remove tabs from SGML.
On lör, 2009-08-15 at 19:13 -0400, Andrew Dunstan wrote: Do we have some recommended emacs settings for editing the docs? Do we need a pgsql-docs mode? There are suggested settings in src/tools/editors/emacs.samples . -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Remove tabs from SGML.
Peter Eisentraut wrote: On lör, 2009-08-15 at 19:13 -0400, Andrew Dunstan wrote: Do we have some recommended emacs settings for editing the docs? Do we need a pgsql-docs mode? There are suggested settings in src/tools/editors/emacs.samples . Thanks. I wonder how I missed that. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] plpythonu datatype conversion improvements
On tis, 2009-05-26 at 16:07 -0700, Caleb Welton wrote:
Patch for plpythonu
Primary motivation of the attached patch is to support handling bytea
conversion allowing for embedded nulls, which in turn allows for
supporting the marshal module.
Secondary motivation is slightly improved performance for conversion
routines of basic datatypes that have simple mappings between
postgres/python.
Primary design is to change the conversion routines from being based
on cstrings to datums, eg:
PLyBool_FromString(const char *) =
PLyBool_FromBool(PLyDatumToOb, Datum);
I have reworked this patch a bit and extended the plpython test suite
around it. Current copy attached.
The remaining problem is that the patch loses domain checking on the
return types, because some paths no longer go through the data type's
input function. I have marked these places as FIXME, and the regression
tests also contain a failing test case for this.
What's needed here, I think, is an API that takes a datum plus type
information and checks whether the datum is valid within the domain. I
haven't found one that is exported, but maybe someone could give a tip.
diff --git a/src/pl/plpython/expected/plpython_record.out b/src/pl/plpython/expected/plpython_record.out
index 9e4645d..c8c4f9d 100644
--- a/src/pl/plpython/expected/plpython_record.out
+++ b/src/pl/plpython/expected/plpython_record.out
@@ -313,13 +313,15 @@ $$ LANGUAGE plpythonu;
SELECT * FROM test_type_record_error1();
ERROR: key second not found in mapping
HINT: To return null in a column, add the value None to the mapping with the key named after the column.
-CONTEXT: PL/Python function test_type_record_error1
+CONTEXT: while creating return value
+PL/Python function test_type_record_error1
CREATE FUNCTION test_type_record_error2() RETURNS type_record AS $$
return [ 'first' ]
$$ LANGUAGE plpythonu;
SELECT * FROM test_type_record_error2();
ERROR: length of returned sequence did not match number of columns in row
-CONTEXT: PL/Python function test_type_record_error2
+CONTEXT: while creating return value
+PL/Python function test_type_record_error2
CREATE FUNCTION test_type_record_error3() RETURNS type_record AS $$
class type_record: pass
type_record.first = 'first'
@@ -328,4 +330,5 @@ $$ LANGUAGE plpythonu;
SELECT * FROM test_type_record_error3();
ERROR: attribute second does not exist in Python object
HINT: To return null in a column, let the returned object have an attribute named after column with value None.
-CONTEXT: PL/Python function test_type_record_error3
+CONTEXT: while creating return value
+PL/Python function test_type_record_error3
diff --git a/src/pl/plpython/expected/plpython_trigger.out b/src/pl/plpython/expected/plpython_trigger.out
index 7591404..dd08303 100644
--- a/src/pl/plpython/expected/plpython_trigger.out
+++ b/src/pl/plpython/expected/plpython_trigger.out
@@ -353,7 +353,8 @@ BEFORE UPDATE ON trigger_test
FOR EACH ROW EXECUTE PROCEDURE stupid4();
UPDATE trigger_test SET v = 'null' WHERE i = 0;
ERROR: TD[new] deleted, cannot modify row
-CONTEXT: PL/Python function stupid4
+CONTEXT: while modifying trigger row
+PL/Python function stupid4
DROP TRIGGER stupid_trigger4 ON trigger_test;
-- TD not a dictionary
CREATE FUNCTION stupid5() RETURNS trigger
@@ -366,7 +367,8 @@ BEFORE UPDATE ON trigger_test
FOR EACH ROW EXECUTE PROCEDURE stupid5();
UPDATE trigger_test SET v = 'null' WHERE i = 0;
ERROR: TD[new] is not a dictionary
-CONTEXT: PL/Python function stupid5
+CONTEXT: while modifying trigger row
+PL/Python function stupid5
DROP TRIGGER stupid_trigger5 ON trigger_test;
-- TD not having string keys
CREATE FUNCTION stupid6() RETURNS trigger
@@ -379,7 +381,8 @@ BEFORE UPDATE ON trigger_test
FOR EACH ROW EXECUTE PROCEDURE stupid6();
UPDATE trigger_test SET v = 'null' WHERE i = 0;
ERROR: TD[new] dictionary key at ordinal position 0 is not a string
-CONTEXT: PL/Python function stupid6
+CONTEXT: while modifying trigger row
+PL/Python function stupid6
DROP TRIGGER stupid_trigger6 ON trigger_test;
-- TD keys not corresponding to row columns
CREATE FUNCTION stupid7() RETURNS trigger
@@ -392,7 +395,8 @@ BEFORE UPDATE ON trigger_test
FOR EACH ROW EXECUTE PROCEDURE stupid7();
UPDATE trigger_test SET v = 'null' WHERE i = 0;
ERROR: key a found in TD[new] does not exist as a column in the triggering row
-CONTEXT: PL/Python function stupid7
+CONTEXT: while modifying trigger row
+PL/Python function stupid7
DROP TRIGGER stupid_trigger7 ON trigger_test;
-- calling a trigger function directly
SELECT stupid7();
diff --git a/src/pl/plpython/expected/plpython_types.out b/src/pl/plpython/expected/plpython_types.out
index 476f329..a03d0cc 100644
--- a/src/pl/plpython/expected/plpython_types.out
+++ b/src/pl/plpython/expected/plpython_types.out
@@ -278,7 +278,7 @@ plpy.info(x, type(x))
return x
$$ LANGUAGE plpythonu;
SELECT * FROM test_type_conversion_bytea('hello world');
-INFO:
Re: [HACKERS] [COMMITTERS] pgsql: Remove tabs from SGML.
Andrew Dunstan wrote: Bruce Momjian wrote: Log Message: --- Remove tabs from SGML. Tags: REL8_3_STABLE Modified Files: -- pgsql/doc/src/sgml/ref: psql-ref.sgml (r1.198.2.1 - r1.198.2.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/psql-ref.sgml?r1=1.198.2.1r2=1.198.2.2) Do we have some recommended emacs settings for editing the docs? Do we need a pgsql-docs mode? Yes, Emacs/PSGML, as mentioned in our docs: http://www.postgresql.org/docs/8.4/static/docguide-authoring.html However, I don't see any mention of tabs there. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
On Sun, 2009-08-16 at 02:02 +0300, Peter Eisentraut wrote: For min, the action happens at or above the min values. For max, the action happens at or below the max value. From the docs, 23.1.4: autovacuum is invoked on any table that might contain XIDs older than the age specified by the configuration parameter autovacuum_freeze_max_age I interpret that to mean that the forced autovacuum run happens above the value. You could reasonably call it the minimum age of relfrozenxid that will cause autovacuum to forcibly run a vacuum. Similarly, you could call vacuum_freeze_min_age the maximum age a tuple can be before a vacuum will freeze it. I'm not trying to be argumentative, I'm just trying to show that it can be confusing if you interpret it the wrong way. The first time I saw those configuration names, I was confused, and ever since, I have to think about it: is that variable called min or max?. My general feeling is that both of these are thresholds. The only real maximum happens near wraparound. With those two particular parameters, the freezing happens exactly between the min and the max value. Thanks, that's a helpful way to remember it. It may be a little obsolete because now the freezing will normally happen between vacuum_freeze_min_age and vacuum_freeze_table_age; but at least I should be able to remember which of the other parameters is min and which one is max. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Remove tabs from SGML.
Bruce Momjian wrote: Andrew Dunstan wrote: Bruce Momjian wrote: Log Message: --- Remove tabs from SGML. Tags: REL8_3_STABLE Modified Files: -- pgsql/doc/src/sgml/ref: psql-ref.sgml (r1.198.2.1 - r1.198.2.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/psql-ref.sgml?r1=1.198.2.1r2=1.198.2.2) Do we have some recommended emacs settings for editing the docs? Do we need a pgsql-docs mode? Yes, Emacs/PSGML, as mentioned in our docs: http://www.postgresql.org/docs/8.4/static/docguide-authoring.html However, I don't see any mention of tabs there. Well, I picked up this from our sample in src/tools/editors and put it in my emacs init file: (defun pgsql-sgml-mode () SGML mode adjusted for PostgreSQL project (interactive) (sgml-mode) (setq indent-tabs-mode nil) (setq sgml-basic-offset 1) ) (setq auto-mode-alist (cons '(\\(postgres\\|pgsql\\).*\\.sgml\\' . pgsql-sgml-mode) auto-mode-alist)) It seems to work. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Remove tabs from SGML.
On Sat, Aug 15, 2009 at 07:13:42PM -0400, Andrew Dunstan wrote: Bruce Momjian wrote: Log Message: --- Remove tabs from SGML. Tags: REL8_3_STABLE Modified Files: -- pgsql/doc/src/sgml/ref: psql-ref.sgml (r1.198.2.1 - r1.198.2.2) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/psql-ref.sgml?r1=1.198.2.1r2=1.198.2.2) Do we have some recommended emacs settings for editing the docs? Do we need a pgsql-docs mode? Perhaps instead of having people who use a particular text editor do some special thing, we could use a CVS (later git) pre-commit hook to look for tabs and reject any commit in this directory or lower that has tabs in it. :) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
On Sun, Aug 16, 2009 at 02:15:39AM +0300, Peter Eisentraut wrote:
On 2009-08-15 at 23:31 +0100, Sam Mason wrote:
Next all you need is to be able to PREPARE them (and somehow access the
parameters from execute) and you'll have nice local functions. :)
Yeah, rather than just making up some new command for execute this
string, this could be generalized as lambda expressions that could be
called whereever an expression is allowed. E.g.
SELECT LAMBDA $$ ... $$;
[..]
SELECT (LAMBDA (x int, y text) $$ ... $$) (37, 'foo');
I can't quite tell if you're being serious or not, you realize that this
leaves open the possibility of doing:
SELECT t.n, f.op, f.fn(t.n)
FROM generate_series(1,10) t(n), (VALUES
('id',LAMBDA (_x int) $$ BEGIN; RETURN _x; END; $$),
('*2',LAMBDA (_x int) $$ BEGIN; RETURN _x*2; END; $$)) f(op,fn)
And of storing lambda abstractions in tables?
--
Sam http://samason.me.uk/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
On Sat, Aug 15, 2009 at 7:15 PM, Peter Eisentrautpete...@gmx.net wrote: On lör, 2009-08-15 at 23:31 +0100, Sam Mason wrote: On Sat, Aug 15, 2009 at 11:34:04PM +0200, Dimitri Fontaine wrote: Nitpicking dept, I think I prefer: DO [ [LANGUAGE] language] $$ ... $$; DO plperl $$ ... $$; DO language plpython $$ ... $$; language is optional and defaults to plpgsql. Yup, sounds nicer. The less globals the better! Next all you need is to be able to PREPARE them (and somehow access the parameters from execute) and you'll have nice local functions. :) Yeah, rather than just making up some new command for execute this string, this could be generalized as lambda expressions that could be called whereever an expression is allowed. E.g. SELECT LAMBDA $$ ... $$; -- if CALL is implemented CALL LAMBDA $$ ... $$; PREPARE foo AS SELECT LAMBDA $$ ... $$; EXECUTE foo; SELECT (LAMBDA (x int, y text) $$ ... $$) (37, 'foo'); I like this idea (although it might not be too easy to implement, not sure), but I think we could still use DO (which is shorter) for the verb. Lambda-calculus is cool, but do is nice and simple. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] GRANT ON ALL IN schema
Robert Haas wrote: I like this idea (although it might not be too easy to implement, not sure), but I think we could still use DO (which is shorter) for the verb. Lambda-calculus is cool, but do is nice and simple. SQL is not Lisp. Simple is good. I didn't think Peter was really very serious. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
