Re: [PATCHES] \prompt for psql
Joshua D. Drake wrote: Alvaro Herrera wrote: Joshua D. Drake wrote: Peter Eisentraut wrote: Magnus Hagander wrote: That also requires a reasonable shell, which all platforms don't have... I think doing any sort of reasonable scripting around psql requires a reasonable shell. Or next someone will suggest implementing loops and conditionals in psql. ... Now that you mention it :) psql is a shell. It is the postgresql shell. I don't see any problem with continuing to extend the postgresql shell to a more functional platform that is independent. At least it'd help those poor people trying to do conditional COMMIT or ROLLBACK based on the transaction status. Maybe it's not such a bad idea. On the other hand, seeing how the history line numbers patch is still nowhere to be seen, I don't think we should be expecting you to send a patch ... ;-) No one would except it from me, I would just embed python ;) or perhaps accept Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] \prompt for psql
On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] wrote: At least it'd help those poor people trying to do conditional COMMIT or ROLLBACK based on the transaction status. The user doesn't need to check the status of the transaction if he just needs to end it. Just fire the END command and it'll take care of whether to COMMIT or ROLLBACK the transaction: edb=# begin; BEGIN edb=# select count(*) from pg_class; count --- 280 (1 row) edb=# select count(*) from pg_class_xyz; ERROR: relation pg_class_xyz does not exist edb=# end; ROLLBACK edb=# Regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | yahoo }.com
Re: [HACKERS] [PATCHES] plpgsql, return can contains any expression
OK, where are we on this patch? without changes. This task have to do anybody who better know PostgreSQL cache system than me. Regards Pavel --- Pavel Stehule wrote: Pavel Stehule [EMAIL PROTECTED] writes: This patch doesn't seem to cope with cases where the supplied tuple has the wrong number of columns, and it doesn't look like it's being careful about dropped columns either. Also, that's a mighty bizarre-looking choice of cache memory context in coerce_to_tuple ... but then again, why are you bothering with a cache at all for temporary arrays? I am sorry, Tom. But I don't understand. I can check number of columns, ofcourse and I'll do it. What cache for temporary arrays do you mean? I thought that making coerce_to_tuple depend on estate-err_func was pretty bizarre, and that there was no need for any cache at all for arrays that need only live as long as the function runs. All you are saving here is a palloc/pfree cycle, which is not worth the obscurantism and risk of bugs (are you sure natts can never change?). No, cache there is ugly. But I don't have idea about more efective implementation of it :-(. First version of this patch was more clean. and little bit slow. This cache save 10%. BTW, if you want this patch to make it into 8.2, it needs to be fixed and resubmitted *very* soon. I understand, but I am not able work on it in next four days. And I need help with it from Neil. It will be for 8.3. Thank you Pavel _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate _ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Feature: POSIX Shared memory support, round 2
Chris Marcellino [EMAIL PROTECTED] writes: Here is a new patch that uses the POSIX api's. It encodes the canonical path (see 'man realpath') of the database's data directory into the shared memory segment name using an strong hash function to make it fit in the shared memory segment name under all cases, without risk of key collision. I find this patch utterly unreadable, because of your cavalier disregard for making the comments match the truth. You have copied-and-pasted the original SysV code and fixed some small fraction of the comments, and I cannot tell which ones still reflect reality --- but I can tell that a lot of them don't. Also, I don't see where this implements any sort of detection of live backends attached to an existing segment, so I don't think you have responded to that objection. Magnus' idea for Windows was to use a segment set up to automatically go away as soon as the last attacher died, but AFAICT that isn't how this works. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] \prompt for psql
On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] wrote: Gurjeet Singh wrote: On 2/9/07, Alvaro Herrera [EMAIL PROTECTED] wrote: At least it'd help those poor people trying to do conditional COMMIT or ROLLBACK based on the transaction status. The user doesn't need to check the status of the transaction if he just needs to end it. Just fire the END command and it'll take care of whether to COMMIT or ROLLBACK the transaction: Hmm, right. Maybe I was thinking in savepoints, which Merlin Moncure is so fond of complaining of ;-) I'm still looking for a use for them. When I find one, I'll give you a heads up. (just so you know, with savepoints came exception blocks, one of my all time favorite features). anyways, instead of complaining, consider it more of 'hopeful nudging' :-) merlin ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] plpgsql, return can contains any expression
Pavel Stehule wrote: OK, where are we on this patch? without changes. This task have to do anybody who better know PostgreSQL cache system than me. How about you submit a version without any caching, but which works correctly; and we worry about optimizations later? --- Pavel Stehule wrote: Pavel Stehule [EMAIL PROTECTED] writes: This patch doesn't seem to cope with cases where the supplied tuple has the wrong number of columns, and it doesn't look like it's being careful about dropped columns either. Also, that's a mighty bizarre-looking choice of cache memory context in coerce_to_tuple ... but then again, why are you bothering with a cache at all for temporary arrays? I am sorry, Tom. But I don't understand. I can check number of columns, ofcourse and I'll do it. What cache for temporary arrays do you mean? I thought that making coerce_to_tuple depend on estate-err_func was pretty bizarre, and that there was no need for any cache at all for arrays that need only live as long as the function runs. All you are saving here is a palloc/pfree cycle, which is not worth the obscurantism and risk of bugs (are you sure natts can never change?). No, cache there is ugly. But I don't have idea about more efective implementation of it :-(. First version of this patch was more clean. and little bit slow. This cache save 10%. BTW, if you want this patch to make it into 8.2, it needs to be fixed and resubmitted *very* soon. I understand, but I am not able work on it in next four days. And I need help with it from Neil. It will be for 8.3. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] plpgsql, return can contains any expression
Pavel Stehule wrote: OK, where are we on this patch? without changes. This task have to do anybody who better know PostgreSQL cache system than me. How about you submit a version without any caching, but which works correctly; and we worry about optimizations later? I can update and send simple version. Regards Pavel Stehule _ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] patch adding new regexp functions
On Fri, 2007-02-09 at 01:08 -0800, Jeremy Drake wrote: Yeah, I try to do that, but this one just barely passed my personal compression threshold. Guess I should raise my threshold :) No, don't pay any attention to me, I'm just lazy :) Here is a new version of the patch which fixes up the documentation a little (should have read it over again before posting). The doing_srf business is rather tortured, and seems an invitation for bugs. ISTM there should be a cleaner way to implement this. For example, would it be possible to put all the common logic into one or more additional functions, and then have SRF vs. non-SRF cases that call into those functions after doing the appropriate initialization? -Neil ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] patch adding new regexp functions
On Fri, 2007-02-09 at 16:33 -0800, Jeremy Drake wrote:
Here is a new version of the patch which eliminates the doing_srf stuff.
* C89 require constant-sized stack allocated arrays, so the coding in
perform_regexp_matches() is non-portable.
* I'm not clear about the control flow in regexp_matches() and
regexp_split(). Presumably it's not possible for the call_cntr to
actually exceed max_calls, so the error message in these cases should be
elog(ERROR), not ereport (the former is for shouldn't happen bug
scenarios, the latter is for user-facing errors). Can you describe the
logic here (e.g. via comments) a bit more?
* The logic in regexp_split (incremented_offset, first_match, etc.) is
pretty ugly and hard to follow. The if condition on line 1037 is
particularly objectionable. Again, ISTM there should be a cleaner way to
do this.
* Try to keep lines to 80 characters or fewer. If the code is wandering
off the right side of the screen all the time, that might be a hint that
it needs simplification.
Attached is a cleaned up version of your patch -- various improvements
throughout, but mostly cosmetic stuff. Do you want to take a look at the
above?
-Neil
Index: doc/src/sgml/func.sgml
===
RCS file: /home/neilc/postgres/cvs_root/pgsql/doc/src/sgml/func.sgml,v
retrieving revision 1.357
diff -c -p -r1.357 func.sgml
*** doc/src/sgml/func.sgml 1 Feb 2007 00:28:16 - 1.357
--- doc/src/sgml/func.sgml 10 Feb 2007 03:20:14 -
***
*** 1446,1451
--- 1446,1464
/row
row
+entryliteralfunctionregexp_matches/function(parameterstring/parameter typetext/type, parameterpattern/parameter typetext/type [,parameterflags/parameter typetext/type])/literal/entry
+entrytypetext[]/type or typesetof record/type (if flags are given)/entry
+entry
+ Return all capture groups resulting from matching POSIX regular
+ expression against the parameterstring/parameter. See
+ xref linkend=functions-matching for more information on pattern
+ matching.
+/entry
+entryliteralregexp_matches('foobarbequebaz', '(bar)(beque)')/literal/entry
+entryliteral{bar,beque}/literal/entry
+ /row
+
+ row
entryliteralfunctionregexp_replace/function(parameterstring/parameter typetext/type, parameterpattern/parameter typetext/type, parameterreplacement/parameter typetext/type [,parameterflags/parameter typetext/type])/literal/entry
entrytypetext/type/entry
entry
***
*** 1458,1463
--- 1471,1488
/row
row
+entryliteralfunctionregexp_split/function(parameterstring/parameter typetext/type, parameterpattern/parameter typetext/type [,parameterflags/parameter typetext/type])/literal/entry
+entrytypesetof text/type/entry
+entry
+ Splits parameterstring/parameter using POSIX regular expression as
+ the delimiter. See xref linkend=functions-matching for more
+ information on pattern matching.
+/entry
+entryliteralregexp_split('hello world', E'\\s+')/literal/entry
+entryliteralhello/literalparaliteralworld/literal/para (2 rows)/entry
+ /row
+
+ row
entryliteralfunctionrepeat/function(parameterstring/parameter typetext/type, parameternumber/parameter typeint/type)/literal/entry
entrytypetext/type/entry
entryRepeat parameterstring/parameter the specified
*** cast(-44 as bit(12)) lineanno
*** 2864,2869
--- 2889,2900
indexterm
primaryregexp_replace/primary
/indexterm
+indexterm
+ primaryregexp_matches/primary
+/indexterm
+indexterm
+ primaryregexp_split/primary
+/indexterm
synopsis
replaceablestring/replaceable SIMILAR TO replaceablepattern/replaceable optionalESCAPE replaceableescape-character/replaceable/optional
*** substring('foobar' from 'o(.)b') line
*** 3112,3118
string containing zero or more single-letter flags that change the
function's behavior. Flag literali/ specifies case-insensitive
matching, while flag literalg/ specifies replacement of each matching
! substring rather than only the first one.
/para
para
--- 3143,3152
string containing zero or more single-letter flags that change the
function's behavior. Flag literali/ specifies case-insensitive
matching, while flag literalg/ specifies replacement of each matching
! substring rather than only the first one. Other supported flags are
! literalm/, literaln/, literalp/, literalw/ and
! literalx/, whose meanings correspond to those shown in
! xref linkend=posix-embedded-options-table.
/para
para
*** regexp_replace('foobarbaz', 'b(..)', E'X
*** 3127,3132
--- 3161,3341
/programlisting
/para
+ para
+ The
