Re: [HACKERS] Initial review of xslt with no limits patch
2010/8/8 David E. Wheeler da...@kineticode.com:
On Aug 7, 2010, at 12:24 AM, Pavel Stehule wrote:
try=# create or replace function try(bool) returns text language plperl AS
'shift';
CREATE FUNCTION
Time: 121.403 ms
try=# select try(true);
try
-
t
(1 row)
I wish this wasn't so.
It must not be - it depends on PL handler implementation. PostgreSQL
call PL handler with binary values. I am thinking so new Python PL can
do it well.
I'm thinking an update to PL/Perl would be useful. Frankly, I'd most like to
see proper array support. But that's another topic.
Valid points. I agree that it would be nicer to use RECORDs:
SELECT foo( row('foo', 1), row('bar', true));
I am not absolutly satisfied - but it's better, than arrays.
Certainly much clearer. But given that we've gone round and round on
allowing non-C functions to use ROWs and gotten nowhere, I don't know that
we'll get any further now. But can you not create a C function that allows
a signature of VARIADIC RECORD?
you can do a variadic over ROW type. We have not a polymorphic arrays
- so isn't possible to write VARIADIC RECORD now.
Ah, right. I guess table types can't be cast to RECORD?
It could be a nice
if we are to define a own composite types with polymorphic fields.
Then you can do:
CREATE TYPE pair AS (key text, value any);
CREATE FUNCTION foo(VARIADIC pair[])
Yes.
other idea is leave arrays - and thinking about key, value collection
as new kind of data types. so maybe
CREATE FUNCTION foo(VARIADIC params COLECTION OF text WITH UNIQUE text KEY)
COLLECTION?
yes, sorry - simply - class where fields can be accessed via specified
index - unique or not unique.
David
--
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] Proposal / proof of concept: Triggers on VIEWs
On 7 August 2010 10:56, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote: The problem is that this isn't even nearly sufficient. I gave this some more thought while I was away, and it seems that I missed at least one more important thing: the WHERE clause. Imagine this query: DELETE FROM view WHERE pk = 1 AND f1 0; Now the trigger function gets called if the row where pk = 1, as seen by the query's snapshot, has f1 0. But if a concurrent transaction sets f1 to 0 before the triggers gets to the row, you end up deleting a row that doesn't match the WHERE clause. I've been playing with this in Oracle and I can confirm that it behaves exactly as my code would do. So in this example, the trigger deletes from the underlying table even after the row has been changed so that it no longer satisfies the original WHERE clause. The case I find worse is that if 2 concurrent transactions do UPDATE view SET f1=f1+1, the value will only be incremented once. For the record, here is the Oracle code in all its gory detail: CREATE TABLE foo(a int, b int); CREATE VIEW foo_v AS SELECT * FROM foo; CREATE TRIGGER del_trig INSTEAD OF DELETE ON foo_v FOR EACH ROW BEGIN DELETE FROM foo WHERE a=:OLD.a; END; / CREATE TRIGGER mod_trig INSTEAD OF UPDATE ON foo_v FOR EACH ROW BEGIN UPDATE foo SET a=:NEW.a, b=:NEW.b WHERE a=:OLD.a; END; / INSERT INTO foo VALUES(1,1); COMMIT; So in the first case, 2 concurrent transactions T1 and T2 are started and do the following: 1. T1 does UPDATE foo_v SET b=0 WHERE a=1; -- Trigger fires and updates foo 2. T2 does DELETE FROM foo_v WHERE a=1 AND b=1; -- This matches 1 row in the VIEW (T1 not committed yet) -- Trigger fires and does DELETE FROM foo WHERE a=1 -- T2 waits for T1 3. T1 commits 4. T2 resumes and deletes the row from foo, since it satisfies a=1 Arguably, this is a deficiency in the trigger function rather than the trigger firing code. It could be fixed by having the trigger re-check all the columns in the table against OLD, but that would be pretty cumbersome for very wide tables, and none of the documented examples I've seen take that approach. The second case is as follows: INSERT INTO foo VALUES(1,1); COMMIT; Then 2 concurrent transactions T1 and T2 are started and do the following: 1. T1 does UPDATE foo_v SET b=b+1 WHERE a=1; -- Trigger fires and does UPDATE foo SET b=2 WHERE a=1; 2. T2 does UDPATE foo_v SET b=b+1 WHERE a=1; -- Trigger fires and does UPDATE foo SET b=2 WHERE a=1; -- T2 waits for T1 3. T1 commits 4. T2 resumes and sets b to 2 as requested inside the trigger So the net result is b=2 rather than b=3 - pretty-much the textbook concurrency example. Surprisingly I don't see too many people complaining about this in Oracle, because to me it seems pretty bad. In PostgreSQL we could fix it by declaring the VIEW query as FOR UPDATE, but that's no good if for example the VIEW was based on an aggregate. Oracle has the same limitations on FOR UPDATE, but also AFAICS it doesn't allow VIEWs to be created using SELECT FOR UPDATE at all. For those migrating code from Oracle, providing this feature as-is might be valuable, since presumably they are not too concerned about these concurrency issues. Ideally we'd want to do better though. Thoughts? Regards, Dean I have a few ideas on how this could be tackled, but I think we need to split these two threads. I still think that having triggers on views without addressing these concurrency concerns is not a good idea, though. Regards, Marko Tiikkaja -- 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] Proposal / proof of concept: Triggers on VIEWs
On 8/8/2010 12:49 PM, Dean Rasheed wrote: On 7 August 2010 10:56, Marko Tiikkajamarko.tiikk...@cs.helsinki.fi wrote: The problem is that this isn't even nearly sufficient. I gave this some more thought while I was away, and it seems that I missed at least one more important thing: the WHERE clause. Imagine this query: DELETE FROM view WHERE pk = 1 AND f1 0; Now the trigger function gets called if the row where pk = 1, as seen by the query's snapshot, has f1 0. But if a concurrent transaction sets f1 to 0 before the triggers gets to the row, you end up deleting a row that doesn't match the WHERE clause. I've been playing with this in Oracle and I can confirm that it behaves exactly as my code would do. So in this example, the trigger deletes from the underlying table even after the row has been changed so that it no longer satisfies the original WHERE clause. The case I find worse is that if 2 concurrent transactions do UPDATE view SET f1=f1+1, the value will only be incremented once. Wow. I'm surprised to hear this. In PostgreSQL we could fix it by declaring the VIEW query as FOR UPDATE, but that's no good if for example the VIEW was based on an aggregate. Oracle has the same limitations on FOR UPDATE, but also AFAICS it doesn't allow VIEWs to be created using SELECT FOR UPDATE at all. Also making all SELECTs on the view FOR UPDATE is not a very good idea.. For those migrating code from Oracle, providing this feature as-is might be valuable, since presumably they are not too concerned about these concurrency issues. Ideally we'd want to do better though. Yes, you might be right. This feature on its on can greatly simplify what people now have to do to get triggers on views. Regards, Marko Tiikkaja -- 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] pg_stat_user_functions' notion of user
On tor, 2010-08-05 at 07:13 -0700, David Fetter wrote: On Thu, Aug 05, 2010 at 04:58:32PM +0300, Peter Eisentraut wrote: pg_stat_user_functions has an inconsistent notion of what user is. Whereas the other pg_stat_user_* views filter out non-user objects by schema, pg_stat_user_functions checks for language internal, which does not successfully exclude builtin functions of language SQL. Is there a reason for this inconsistency? If I had to hazard a guess, it would be that the functionality was written over time by different people, not all of whom were using the same criteria for coherence. Would anyone object to changing it to make it more consistent with other others? And since we're jollily making catalog changes in 9.0 still, could this also be backpatched? -- 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] Surprising dead_tuple_count from pgstattuple
Gordon Shannon wrote: If it was HOT prune, can anyone summarize what that does? Get a copy of the PostgreSQL source, and read this file: src/backend/access/heap/README.HOT -Kevin -- 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] Initial review of xslt with no limits patch
On 06/08/10 17:50, Pavel Stehule wrote: attached updated patch with regression test Bravely ignoring the quotation/varidic/favourite_scheme_here conversations, I've taken a look at the patch as is. Thanks to Tom's input I can now correctly drive the function. I can also report that code is now behaving in the expected way. I have two other observations, more directed at the community than Pavel: 1) XML2 is largely undocumented, giving rise to the problems encountered. Since the module is deprecated anyways, does it make more sense to get xslt handling moved into core and get it fully documented? 2) Pavel's regression test exposes a bug in libxslt. The stylesheet declares 5 parameters, but uses 12. Simplifying, take the stylesheet: xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0 xsl:output method=xml omit-xml-declaration=yes indent=yes/ xsl:strip-space elements=*/ xsl:param name=n1/ xsl:template match=* xsl:element name=samples xsl:element name=sample xsl:value-of select=$n1/ /xsl:element xsl:element name=sample xsl:value-of select=$n2/ /xsl:element /xsl:element /xsl:template /xsl:stylesheet and run the command: ~/temp$ xsltproc --stringparam n2 v2 Untitled2.xsl Untitled1.xml samples sample/ samplev2/sample /samples All looks good. However if you run: ~/temp$ xsltproc --stringparam n1 v1 Untitled2.xsl Untitled1.xml runtime error: file Untitled2.xsl line 28 element value-of Variable 'n2' has not been declared. xmlXPathCompiledEval: evaluation failed runtime error: file Untitled2.xsl line 28 element value-of XPath evaluation returned no result. samples samplev1/sample sample/ /samples The xslt_process function ignores these errors and returns cleanly. To summarize, the bug in libxslt is that it allows the processing of unnamed parameters - most other parsers would reject this stylesheet. Secondly, the xslt_process does not return the errors reported when running without passing the unnamed parameter. Personally I would like to see this documented and moved to core so that the whole of xml2 can be dropped. I also think that the errors should be reported, even if libxslt doesn't behave properly in all scenarios. Of course there's that whole other issue around how you pass the parameters in the first place that needs resolving too... Regards, -- Mike Fowler Registered Linux user: 379787 -- 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] pg_stat_user_functions' notion of user
On Sun, Aug 08, 2010 at 03:25:06PM +0300, Peter Eisentraut wrote: On tor, 2010-08-05 at 07:13 -0700, David Fetter wrote: On Thu, Aug 05, 2010 at 04:58:32PM +0300, Peter Eisentraut wrote: pg_stat_user_functions has an inconsistent notion of what user is. Whereas the other pg_stat_user_* views filter out non-user objects by schema, pg_stat_user_functions checks for language internal, which does not successfully exclude builtin functions of language SQL. Is there a reason for this inconsistency? If I had to hazard a guess, it would be that the functionality was written over time by different people, not all of whom were using the same criteria for coherence. Would anyone object to changing it to make it more consistent with other others? And since we're jollily making catalog changes in 9.0 still, could this also be backpatched? +1 for both. 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 iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics 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] scheduling
Robert Haas robertmh...@gmail.com writes: Do we have a projected data for the next 9.0 wrap, and will it be beta5 or rc1? No, and don't know ;-). It won't be till after the 15th because assorted people are on vacation. Perhaps a reasonable plan is to wrap on the 19th (week from Thursday), and to decide mid next week whether we feel good about calling it rc1. How much should we worry about the remaining open items? http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items I am inclined to say that all three of the items currently on the list need to be addressed in some way before we move forward... or at least the last two. * ExplainOnePlan handles snapshots differently than ProcessQuery * Backup procedure is wrong? * Walreceiver crashes in AIX I don't think that now is an appropriate time to be messing with the first item. It is not a 9.0 regression --- the behavior has been that way for years --- and it is not closely related to any changes we made in 9.0. If we'd discovered the issue after 9.0.0 release there would have been absolutely no suggestion of back-patching a change. Also, it didn't seem to me that we had consensus on what to do about it, so the thought of a hasty change scares me. We do need to resolve the others. 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] pg_stat_user_functions' notion of user
Peter Eisentraut pete...@gmx.net writes: On tor, 2010-08-05 at 07:13 -0700, David Fetter wrote: On Thu, Aug 05, 2010 at 04:58:32PM +0300, Peter Eisentraut wrote: pg_stat_user_functions has an inconsistent notion of what user is. Whereas the other pg_stat_user_* views filter out non-user objects by schema, pg_stat_user_functions checks for language internal, which does not successfully exclude builtin functions of language SQL. Is there a reason for this inconsistency? Would anyone object to changing it to make it more consistent with other others? And since we're jollily making catalog changes in 9.0 still, could this also be backpatched? The reason for the inconsistency is that the underlying behavior is different: fmgr automatically doesn't collect stats for internal functions. And yes I will object to trying to change that right now. It's not just a catalog change. 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] Initial review of xslt with no limits patch
On Aug 7, 2010, at 11:05 PM, Pavel Stehule wrote: COLLECTION? yes, sorry - simply - class where fields can be accessed via specified index - unique or not unique. Like in Oracle? From: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/collections.htm A collection is an ordered group of elements, all of the same type. It is a general concept that encompasses lists, arrays, and other datatypes used in classic programming algorithms. Each element is addressed by a unique subscript. There are no keys. Best, David -- 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] Initial review of xslt with no limits patch
2010/8/8 David E. Wheeler da...@kineticode.com: On Aug 7, 2010, at 11:05 PM, Pavel Stehule wrote: COLLECTION? yes, sorry - simply - class where fields can be accessed via specified index - unique or not unique. Like in Oracle? From: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/collections.htm yes, can be some like it. But I would to allow a non unique indexes A collection is an ordered group of elements, all of the same type. It is a general concept that encompasses lists, arrays, and other datatypes used in classic programming algorithms. Each element is addressed by a unique subscript. There are no keys. ok - I didn't use a correct name - so indexed set is better. Best, David -- 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] pg_stat_transaction patch
Itagaki Takahiro itagaki.takah...@gmail.com writes: Accessor functions to get so far collected statistics for the current transaction https://commitfest.postgresql.org/action/patch_view?id=301 The only issue in the patch is too long view and function names: - pg_stat_transaction_user_tables (31 chars) - pg_stat_get_transaction_tuples_hot_updated (42 chars) - pg_stat_get_transaction_function_self_time (42 chars) Since we've already used _xact_ in some system objects, we could replace _transaction_ parts with _xact_. It will save 7 key types per query ;-) Applied, with assorted corrections - * Renamed *_transaction_* to *_xact_* as suggested by Itagaki-san. * Removed functions and view columns for delta live/dead tuple counts. * Marked functions as volatile ... they certainly aren't stable. * Got rid of use of get_tabstat_entry() to fetch table entries. That function forcibly creates tabstat entries if they weren't there before, which was absolutely not what we want here: it'd result in bloating the tabstat arrays with entries for tables the current transaction actually never touched. Worse, since you weren't passing the correct isshared flag for the particular relation, the entries could be created with the wrong isshared setting, leading to misbehavior if they did get used later in the transaction. We have to use a find-don't-create function here. * Fixed bogus handling of inserted/updated/deleted counts --- you need to add on the pending counts for all open levels of subtransaction. * Assorted docs improvement and other minor polishing. BTW, I notice that the patch provides pg_stat_get_xact_blocks_fetched() and pg_stat_get_xact_blocks_hit(), but doesn't build any views on top of them. Was this intentional? Providing a full complement of pg_statio_xact_* views seems like overkill to me, but maybe that was where you were intending to go and forgot. If the functions are there then anyone who needs the functionality can easily build their own views atop them, so this might be an intentional compromise position, but I'm not sure. Or maybe we should decide that intratransaction statio numbers aren't likely to be of interest to anybody, and drop the functions too. 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] Initial review of xslt with no limits patch
Pavel Stehule wrote: I didn't use a correct name - so indexed set is better. How would such a thing differ from a RAM-based local temporary table? -Kevin -- 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] review: psql: edit function, show function commands patch
Pavel Stehule pavel.steh...@gmail.com writes: updated patch attached What exactly is the point of the \sf command? It seems like quite a lot of added code for a feature that nobody has requested, and whose definition is about as ad-hoc as could be. Personally I'd much sooner use \ef for looking at a function definition. I think if \sf had been submitted as a separate patch, rather than being snuck in with a feature people do want, it wouldn't be accepted. The current patch doesn't even compile warning-free :-( command.c: In function `exec_command': command.c:559: warning: `lineno' might be used uninitialized in this function command.c: In function `editFile': command.c:1729: warning: `editor_lineno_switch' might be used uninitialized in this function 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] Initial review of xslt with no limits patch
On Aug 8, 2010, at 9:10 AM, Pavel Stehule wrote: There are no keys. ok - I didn't use a correct name - so indexed set is better. Hash? David -- 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] review: xml_is_well_formed
Peter Eisentraut pete...@gmx.net writes:
On lör, 2010-07-31 at 13:40 -0400, Robert Haas wrote:
I think the point of this function is to determine whether a cast to
xml will throw an error. The behavior should probably match exactly
whatever test would be applied there.
Maybe there should be
xml_is_well_formed()
xml_is_well_formed_document()
xml_is_well_formed_content()
I agree that consistency with SQL/XML is desirable, but for someone
coming from the outside, the unqualified claim that 'foo' is well-formed
XML might sound suspicious.
I think I agree with the later discussion that xml_is_well_formed()
should tell you whether a cast to xml would succeed (and hence it has to
pay attention to XMLOPTION). However, it seems to also make sense to
provide the other two functions suggested here, both to satify people
who know XML and to offer tests that will tell you whether
XMLPARSE ( { DOCUMENT | CONTENT } value ) will succeed.
Merging the three cases into one function doesn't seem like a win
for either compatibility or usability.
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] review: psql: edit function, show function commands patch
2010/8/8 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: updated patch attached What exactly is the point of the \sf command? It seems like quite a lot of added code for a feature that nobody has requested, and whose definition is about as ad-hoc as could be. Personally I'd much sooner use \ef for looking at a function definition. I think if \sf had been submitted as a separate patch, rather than being snuck in with a feature people do want, it wouldn't be accepted. I disagree. Now, you cannot to show a detail of function in well readable form. Personally I prefer \sf+ form. Because I can see line numbers, but \sf form is important for some copy paste operations. I don't think, so \ef can replace \sf. It is based on my personal experience. When I have to do some fast fix or fast decision I need to see a source code of some functions (but I am in customer's environment). Starting a external editor is slow and usually you can not there to start your preferable editor. If I return back then my first idea was to modify current \df command to some practical form. Later in discussion was decided so new command will be better. The current patch doesn't even compile warning-free :-( command.c: In function `exec_command': command.c:559: warning: `lineno' might be used uninitialized in this function command.c: In function `editFile': command.c:1729: warning: `editor_lineno_switch' might be used uninitialized in this function there is some strange - it didn't find it in my environment. But I recheck it tomorrow morning. Regards Pavel Stehule 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] Initial review of xslt with no limits patch
2010/8/8 Kevin Grittner kevin.gritt...@wicourts.gov: Pavel Stehule wrote: I didn't use a correct name - so indexed set is better. How would such a thing differ from a RAM-based local temporary table? temporary tables are too heavy for this purposes. In SQL environment I expecting a transactional behave from tables. It isn't necessary. Next tables are strict structure. And it can be useless for storing a set of parameters. -Kevin -- 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] Initial review of xslt with no limits patch
2010/8/8 David E. Wheeler da...@kineticode.com: On Aug 8, 2010, at 9:10 AM, Pavel Stehule wrote: There are no keys. ok - I didn't use a correct name - so indexed set is better. Hash? Just only hash isn't good model, because I sometimes we would prefer a ordered set Regards Pavel David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Review: Re: [PATCH] Re: [HACKERS] Adding xpath_exists function
Mike Fowler m...@mlfowler.com writes: On 06/08/10 20:55, Peter Eisentraut wrote: On fre, 2010-08-06 at 09:04 +0100, Mike Fowler wrote: If the patch is to be committed, does it make sense for me to refine it such that it uses the new xpath internal function you extracted in the xmlexists patch? Yes, you can probably shrink this patch down to about 20 lines. Updated the patch so that it will apply to head and re-worked the function to use the new xpath internal function. Applied with minor corrections (improved docs, fixed regression tests, adjusted OIDs for CVS HEAD). 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] pg_stat_user_functions' notion of user
On sön, 2010-08-08 at 11:59 -0400, Tom Lane wrote: The reason for the inconsistency is that the underlying behavior is different: fmgr automatically doesn't collect stats for internal functions. Sure it does: When they are defined in language SQL. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ALTER TYPE extensions
For the next review cycle, here is a patch that adds some ALTER TYPE subcommands for composite types: ALTER TYPE ... ADD ATTRIBUTE ALTER TYPE ... DROP ATTRIBUTE ALTER TYPE ... ALTER ATTRIBUTE ... SET DATA TYPE ALTER TYPE ... RENAME ATTRIBUTE These work similarly to the analogous ALTER TABLE / $ACTION COLUMN commands. The first two above are from the SQL standard. diff --git a/doc/src/sgml/ref/alter_type.sgml b/doc/src/sgml/ref/alter_type.sgml index e2fec32..ade300f 100644 --- a/doc/src/sgml/ref/alter_type.sgml +++ b/doc/src/sgml/ref/alter_type.sgml @@ -23,9 +23,17 @@ PostgreSQL documentation refsynopsisdiv synopsis -ALTER TYPE replaceable class=PARAMETERname/replaceable RENAME TO replaceable class=PARAMETERnew_name/replaceable +ALTER TYPE replaceable class=PARAMETERname/replaceable replaceable class=PARAMETERaction/replaceable [, ... ] ALTER TYPE replaceable class=PARAMETERname/replaceable OWNER TO replaceable class=PARAMETERnew_owner/replaceable +ALTER TYPE replaceable class=PARAMETERname/replaceable RENAME ATTRIBUTE replaceable class=PARAMETERattribute_name/replaceable TO replaceable class=PARAMETERnew_attribute_name/replaceable +ALTER TYPE replaceable class=PARAMETERname/replaceable RENAME TO replaceable class=PARAMETERnew_name/replaceable ALTER TYPE replaceable class=PARAMETERname/replaceable SET SCHEMA replaceable class=PARAMETERnew_schema/replaceable + +phrasewhere replaceable class=PARAMETERaction/replaceable is one of:/phrase + +ADD ATTRIBUTE replaceable class=PARAMETERattribute_name/replaceable replaceable class=PARAMETERdata_type/replaceable +DROP ATTRIBUTE [ IF EXISTS ] replaceable class=PARAMETERattribute_name/replaceable +ALTER ATTRIBUTE replaceable class=PARAMETERattribute_name/replaceable [ SET DATA ] TYPE replaceable class=PARAMETERdata_type/replaceable /synopsis /refsynopsisdiv @@ -34,6 +42,76 @@ ALTER TYPE replaceable class=PARAMETERname/replaceable SET SCHEMA replace para commandALTER TYPE/command changes the definition of an existing type. + There are several subforms: + + variablelist + varlistentry +termliteralADD ATTRIBUTE/literal/term +listitem + para + This form adds a new attribute to a composite type, using the same syntax as + xref linkend=SQL-CREATETYPE. + /para +/listitem + /varlistentry + + varlistentry +termliteralDROP ATTRIBUTE [ IF EXISTS ]/literal/term +listitem + para + This form drops an attribute from a composite type. + If literalIF EXISTS/literal is specified and the attribute + does not exist, no error is thrown. In this case a notice + is issued instead. + /para +/listitem + /varlistentry + + varlistentry +termliteralSET DATA TYPE/literal/term +listitem + para + This form changes the type of an attribute of a composite type. + /para +/listitem + /varlistentry + + varlistentry +termliteralOWNER/literal/term +listitem + para + This form changes the owner of the type. + /para +/listitem + /varlistentry + + varlistentry +termliteralRENAME/literal/term +listitem + para + This form changes the name of the type or the name of an + individual attribute of a composite type. + /para +/listitem + /varlistentry + + varlistentry +termliteralSET SCHEMA/literal/term +listitem + para + This form moves the type into another schema. + /para +/listitem + /varlistentry + /variablelist + /para + + para + The literalADD ATTRIBUTE/literal, literalDROP + ATTRIBUTE/literal, and literalALTER ATTRIBUTE/literal actions + can be combined into a list of multiple alterations to apply in + parallel. For example, it is possible to add several attributes + and/or alter the type of several attributes in a single command. /para para @@ -90,6 +168,34 @@ ALTER TYPE replaceable class=PARAMETERname/replaceable SET SCHEMA replace /listitem /varlistentry + varlistentry + termreplaceable class=PARAMETERattribute_name/replaceable/term + listitem + para +The name of the attribute to add, alter, or drop. + /para + /listitem + /varlistentry + + varlistentry + termreplaceable class=PARAMETERnew_attribute_name/replaceable/term + listitem + para +The new name of the attribute begin renamed. + /para + /listitem + /varlistentry + + varlistentry + termreplaceable class=PARAMETERdata_type/replaceable/term + listitem + para +The data type of the attribute to add, or the new type of the +attribute to alter. + /para + /listitem + /varlistentry + /variablelist /para /refsect1 @@ -119,14 +225,21 @@ ALTER TYPE email OWNER TO joe; ALTER TYPE email SET SCHEMA customers; /programlisting /para + + para + To add a new attribute to a type: +programlisting +ALTER TYPE compfoo ADD ATTRIBUTE f3 int;
Re: [HACKERS] review: xml_is_well_formed
On Sun, Aug 8, 2010 at 1:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On lör, 2010-07-31 at 13:40 -0400, Robert Haas wrote:
I think the point of this function is to determine whether a cast to
xml will throw an error. The behavior should probably match exactly
whatever test would be applied there.
Maybe there should be
xml_is_well_formed()
xml_is_well_formed_document()
xml_is_well_formed_content()
I agree that consistency with SQL/XML is desirable, but for someone
coming from the outside, the unqualified claim that 'foo' is well-formed
XML might sound suspicious.
I think I agree with the later discussion that xml_is_well_formed()
should tell you whether a cast to xml would succeed (and hence it has to
pay attention to XMLOPTION). However, it seems to also make sense to
provide the other two functions suggested here, both to satify people
who know XML and to offer tests that will tell you whether
XMLPARSE ( { DOCUMENT | CONTENT } value ) will succeed.
Merging the three cases into one function doesn't seem like a win
for either compatibility or usability.
+1. I didn't realize how funky the XMLOPTION stuff was at the start
of this discussion; I think your analysis here is spot-on.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] parallel quicksort
Hi everyone, I've been playing around with a process based parallel quicksort (http://github.com/markwkm/quicksort) and I tried to shoehorn it into postgres because I wanted to see if I could sort more than integers. I've attached a patch that creates a new GUC to control the degree of parallelism and only modified the quicksort algorithm in quicksort.c. Trying to 'make install' quickly shows me the patch breaks zic and Andrew Gierth further pointed out on irc (a couple months back now) that user defined comparison functions won't work as expected in the forked processes (if I remember that correctly). Hoping this could be useful, I wanted to put out what I had so far and see how far away this is from something workable. Not to mention that there are probably some improvements that could be make to the parallel quicksort algorithm. In case anyone is interested in a parallel merge sort algorithm, I have started something fairly basic here: http://github.com/markwkm/mergesort Regards, Mark pqs-1.patch Description: Binary data -- 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] review: psql: edit function, show function commands patch
On Sun, Aug 8, 2010 at 1:14 PM, Tom Lane t...@sss.pgh.pa.us wrote: Pavel Stehule pavel.steh...@gmail.com writes: updated patch attached What exactly is the point of the \sf command? It seems like quite a lot of added code for a feature that nobody has requested, and whose definition is about as ad-hoc as could be. Personally I'd much sooner use \ef for looking at a function definition. I think if \sf had been submitted as a separate patch, rather than being snuck in with a feature people do want, it wouldn't be accepted. I rather like \sf, actually; in fact, I think there's a decent argument to be made that it's more useful than the line-numbering stuff for \ef. I don't particularly like the name \sf, but that's more because I think backslash commands are a fundamentally unscalable approach to providing administrative functionality than because I think there's a better option in this particular case. It's rather hard right now to get a function definition out of the database in easily cut-and-pastable format. pg_dump won't do it, unless you'd like to dump the whole schema (I think we should add an option there, too, actually). Using \ef is reasonable but if the definition is more than one page and you actually want to cut-and-paste it rather than writing it to a file some place, it's not convenient. (Hopefully you understand the problem I'm talking about here: cut-and-paste can scroll past one screen, but the editor doesn't actually write it out that way; it displays it a page at a time.) Now, admittedly, this is only a minor convenience we're talking about: and if this get shot down I won't cry into my beer, but I do think it's useful. The current patch doesn't even compile warning-free :-( command.c: In function `exec_command': command.c:559: warning: `lineno' might be used uninitialized in this function command.c: In function `editFile': command.c:1729: warning: `editor_lineno_switch' might be used uninitialized in this function That obviously needs to be fixed. (BTW, if you want to take this one instead of me, that's fine. Otherwise, I'll get to it this week.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] Initial review of xslt with no limits patch
On Sun, Aug 8, 2010 at 11:36 AM, Mike Fowler m...@mlfowler.com wrote: On 06/08/10 17:50, Pavel Stehule wrote: attached updated patch with regression test Bravely ignoring the quotation/varidic/favourite_scheme_here conversations, Thank you! I've taken a look at the patch as is. Excellent. Thanks to Tom's input I can now correctly drive the function. I can also report that code is now behaving in the expected way. I have two other observations, more directed at the community than Pavel: 1) XML2 is largely undocumented, giving rise to the problems encountered. Since the module is deprecated anyways, does it make more sense to get xslt handling moved into core and get it fully documented? Yes, I think that would be better. 2) Pavel's regression test exposes a bug in libxslt. The stylesheet declares 5 parameters, but uses 12. Simplifying, take the stylesheet: I'm not sure whether there's anything we can do about this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] pg_stat_user_functions' notion of user
Peter Eisentraut pete...@gmx.net writes: On sön, 2010-08-08 at 11:59 -0400, Tom Lane wrote: The reason for the inconsistency is that the underlying behavior is different: fmgr automatically doesn't collect stats for internal functions. Sure it does: When they are defined in language SQL. Those aren't internal (in the sense of prolang = 12) functions. The big picture here is that we intentionally suppressed collection of stats for internal functions because of performance concerns. The test in the pg_stat_user_functions view is not about restricting what functions can be shown in the view; it's just a small performance optimization to avoid calling the low-level pg_stat_get_ functions for pg_proc entries that we know a-priori won't have any stats. If we added a clause to hide functions based on their schema, we would logically need to provide the full set of pg_stat_all_functions, pg_stat_sys_functions, and pg_stat_user_functions views. Otherwise the views would provide no way to get at stats for functions that the collection mechanism is perfectly willing to collect stats for. I'm not convinced that it's worth the trouble, but we'd have to do it if we decide to filter on schema as well as prolang. 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] pg_stat_user_functions' notion of user
On 8/8/10 8:40 AM, David Fetter wrote: Would anyone object to changing it to make it more consistent with other others? And since we're jollily making catalog changes in 9.0 still, could this also be backpatched? I'd object. It's not a bug (arguable spec, maybe, but working as spec'd), and it's not trivial, and it's functionality we've already released. -1 from me for doing anything in 9.0 -- -- Josh Berkus PostgreSQL Experts Inc. http://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] Patch review: make RAISE without arguments work like Oracle
David Fetter da...@fetter.org writes: I'd like to mark this as Ready for Committer :) Applied with corrections. The main noncosmetic change was that the estate field has to be saved and restored, not just arbitrarily reset to null after running a handler. Otherwise nested exception handlers interfere with each other in surprising ways. 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] Initial review of xslt with no limits patch
Robert Haas robertmh...@gmail.com writes: On Sun, Aug 8, 2010 at 11:36 AM, Mike Fowler m...@mlfowler.com wrote: 1) XML2 is largely undocumented, giving rise to the problems encountered. Since the module is deprecated anyways, does it make more sense to get xslt handling moved into core and get it fully documented? Yes, I think that would be better. I'm hesitant to consider pulling this into core when there's so little consensus on how it ought to act. It'd be better to have a solid, widely used contrib module *first*, rather than imagine that pulling it into core is somehow a cure for its problems. 2) Pavel's regression test exposes a bug in libxslt. The stylesheet declares 5 parameters, but uses 12. Simplifying, take the stylesheet: I'm not sure whether there's anything we can do about this. We should file a bug report with the libxslt authors, obviously. 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] review: psql: edit function, show function commands patch
Robert Haas robertmh...@gmail.com writes: On Sun, Aug 8, 2010 at 1:14 PM, Tom Lane t...@sss.pgh.pa.us wrote: What exactly is the point of the \sf command? I rather like \sf, actually; in fact, I think there's a decent argument to be made that it's more useful than the line-numbering stuff for \ef. I don't particularly like the name \sf, but that's more because I think backslash commands are a fundamentally unscalable approach to providing administrative functionality than because I think there's a better option in this particular case. It's rather hard right now to get a function definition out of the database in easily cut-and-pastable format. Um, but \sf *doesn't* give you anything that's usefully copy and pasteable. And if that were the goal, why doesn't it have an option to write to a file? But it's really the line numbers shoved in front that I'm on about here. I can't see *any* use for that behavior except to figure out what part of your function an error message with line number is referring to; and as I said upthread, there are better ways to be attacking that problem. If you've got a thousand-line function (yes, they're out there) do you really want to be scrolling through \sf output to find out what line 714 is? 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
[HACKERS] more personal copyrights
Hi, A few months ago Bruce was doing a hunting of personal Copyrights notices, but i still found a lot of files copyrighted to: Regents of the University of California and other files copyrighted to individuals (ej: almost everything inside src/backend/regex is copyrighted to Henry Spencer) there's something we can/need to do about it? I can make a list if anyone is interested showing what files are still copyrighted to something different to 'PostgreSQL Global Development Group' -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- 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] more personal copyrights
A few months ago Bruce was doing a hunting of personal Copyrights notices, but i still found a lot of files copyrighted to: Regents of the University of California and other files copyrighted to individuals (ej: almost everything inside src/backend/regex is copyrighted to Henry Spencer) there's something we can/need to do about it? I can make a list if anyone is interested showing what files are still copyrighted to something different to 'PostgreSQL Global Development Group' I am not sure if we could arbitrarily change the copyright notices without explicit permissions from the original authors. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
