Re: [PATCHES] WIP patch - INSERT-able log statements
Added -hackers to CC:. On 2/18/07, Greg Smith [EMAIL PROTECTED] wrote: I've thought a bit about how to implement this TODO already (I have a log file parser and I hate maintaining it) Any problem using pgFouine? Also, I feel that supporting the whole log_line_prefix syntax for this feature is not just overkill, it's a bad idea. Output everything in a standard, complete format instead, and then it becomes easy for the community at large to build tools on top of that to analyze the log database entries instead of having so many ad-hoc approaches. You want a subset, use a view or copy just the fields you want into another table. I would guess this simplifies the patch as well. I agree with you on this point. We need every information we can put in the database (database, user and so on) in a structured way. Logging statements is not the only thing to do IMHO. Logging errors in another table is important too. I'm pretty sure there are a lot people who don't know if there are errors in their statements. Anyway, if something is developed to do that, I'll extend pgFouine to support it (or I'll write another application to do it) and I'm pretty sure others will do. The most annoying and difficult part of the work on pgFouine/PQA/... is to maintain the parser. If we don't have to do that anymore, we'll have more time to think about new features. In fact, it was a long plan for pgFouine to be able to store the results of its analysis in a database so it's a good news if it's implemented in core. -- Guillaume ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] further bootstrap cleanup
Alvaro Herrera wrote: Here is a patch further cleaning up dummy process startup and the bootstrap code itself a little. Could we please call the dummy processes something else? Dummy seems a bit belittling for such important things like bgwriter and the startup process. How about worker or helper process? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] \prompt for psql
Chad Wagner wrote: 1. if pset.notty is set and '-f' switch is not set then use simple_prompt -- deals with SQL script redirection case and '-f' is not used, and not interactive 2. else then use gets_fromFile(stdin) or some other alternative? (read from stdin) That seems a bit too complicated. Programs generally shouldn't behave differently depending on whether stdin or stdout are redirected. I was just raising the point because the shell command read reads from stdin and is quite useful noninteractively. I'm not sure, however, that the proposed \prompt command has much use in that regard. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] patch for contrib/xml2
Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian wrote: Should we revisit xpath_array() for 8.3, or is this all in core now? Not yet, but we are currently discussing how. Uh, was this handled? Not yet. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] patch adding new regexp functions
Jeremy Drake wrote: As for the argument about array vs setof, I could see doing both to end the argument of which one is really superior for any particular problem. regexp_split(string text, pattern text[, flags text]) returns setof text regexp_split_array(string text, pattern text[. flags text[, limit int]]) returns text[] Since you are not splitting an array but returning an array, I would think that regexp_split_to_array would be better, and the other should then be regexp_split_to_table. But why does the second one have a limit and the first one doesn't? Is this because you rely on the LIMIT clause to do the same? Is there a guarantee that LIMIT on a table function makes a consistent order? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Allow \pset to parse on or off for boolean values
This is a TODO item: o Allow psql \pset boolean variables to set to fixed values, rather than toggle Basically allows for: test=# \pset expanded on Expanded display is on. test=# \pset footer off Default footer is off. test=# \pset footer Default footer is on. test=# \pset footer Default footer is off. test=# \pset footer Default footer is on. Basically the change is to check if value in do_pset is != NULL to call ParseVariableBool to get a true/false and set the value directly, of the second parameter is not provided then the old logic of toggling is supported. The pset variables that are adjusted are: expanded numericlocale tuples_only pager (supports on/off/always now) footer psql_pset_parsebool.diff Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] patch for contrib/xml2
Please wait a little bit, I'll send updated patch (xpath_array() in core)
tonight or tomorrow.
It seems so that there is no actual needs in other xpath-functions...
Just to recall:
- xpath_array() produces xml[] as a result -- so, it's possible to process
then any of returned XML fragments, with proper type casting;
- also xpath_boolean(), xpath_string() and xpath_number() were proposed,
according current functions from contrib/xml2. They are intended to return
scalar value, first found by XPath expression. I saw serious problems with
them -- e.g. it's quite ugly to return always first value of the sequence
(but it might be useful in practice, surely) and, moreover, from my POV,
xpath_string('/a/text()', 'avery bsimple/b example/a') should
produce 'very simple example' (not 'very ' and not 'very example') -- due
to XML semantics. This differs xpath_string() from other two...
So, my proposal is to include only one function and forget about that three
until we have a better vision ...
I'll raise other (less important) questions with patch sent, shortly.
On 2/18/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Should we revisit xpath_array() for 8.3, or is this all in core now?
Not yet, but we are currently discussing how.
Uh, was this handled?
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Best regards,
Nikolay
Re: [PATCHES] patch adding new regexp functions
On Sun, 18 Feb 2007, Jeremy Drake wrote: On Sun, 18 Feb 2007, Peter Eisentraut wrote: regexp_split(string text, pattern text[, flags text]) returns setof text regexp_split_array(string text, pattern text[. flags text[, limit int]]) returns text[] Since you are not splitting an array but returning an array, I would think that regexp_split_to_array would be better, and the other should then be regexp_split_to_table. OK But why does the second one have a limit and the first one doesn't? I will rename the functions regexp_split_to_(table|array) and I will add an optional limit parameter to the regexp_split_to_table function, for consistency and to avoid ordering concerns with LIMIT. -- Sometimes I worry about being a success in a mediocre world. -- Lily Tomlin ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] patch adding new regexp functions
Jeremy Drake [EMAIL PROTECTED] writes: I will rename the functions regexp_split_to_(table|array) and I will add an optional limit parameter to the regexp_split_to_table function, for consistency and to avoid ordering concerns with LIMIT. I'd go the other way: get rid of the limit option all 'round. It seems like fairly useless complexity. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] WIP patch - INSERT-able log statements
On Tue, 20 Feb 2007, FAST PostgreSQL wrote: I think adding the 'format' of the log as an option in the 'destination' may be confusing. We can have a new boolean variable like 'output_sql_log' or 'log_sql_format' which will trigger the output of INSERT-able log in addition to syslog/stderr/eventlog in text format as it is now. What's confusing about it? Consider this hypothetical postgresql.conf snippet: log_destination = 'stderr,sql' # Valid values are combinations of # stderr, syslog, sql, and eventlog, # depending on platform. # These are relevant when logging to sql: log_sql_table = 'pg_log' # Table SQL formatted logs INSERT into # Default is 'pg_log' Adding new GUC variables isn't without cost; no reason to add a new one when there's a perfectly good destination one already whose syntax is completely appropriate for this task. I personally would just ignore the duration two entries per statement problem and make that the log analyzer software's job to fix, but I'm likely biased here because I don't ever do anything with that data. My preference would be for the sql-logs to use the same variables as that of redirect_stderr. In the directory mentioned by the user on log_directory we just output the sql logs in a file with an '.SQL' appended to the filename specified by the user in log_filename. This also means we can make use of the log_truncation and log_rotate options (I hope. I will have a look at that). You're talking along the same lines here I was trying to suggest in my previous message. Keep all the current behavior as far as truncation and rotation go, just provide a different name for the file. If you just appended a suffix like .sql to the existing name, that would remove another GUC variable requirement. I think eventually people will complain about this, and want a separately formatted filename altogether, but there's nothing wrong with the approach you suggest for a first version of this feature. I know I'm so desparate for a better solution to log importing that I'd be happy with any workable improvement. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 6: explain analyze is your friend
