Re: [PATCHES] WIP patch - INSERT-able log statements

2007-02-17 Thread Greg Smith
On Sat, 17 Feb 2007, FAST PostgreSQL wrote: #log_output_type = 'text' #Valid values are 'SQL' or 'text' Defaults to 'text' which is status quo. If it is set to 'SQL' log will be output as INSERT commands. This assumes someone wants either the INSERT-able logs or the current, easily readable

Re: [PATCHES] [BUGS] BUG #2977: dow doesn't conform to ISO-8601

2007-02-17 Thread Bruce Momjian
I have implemented 'isodow' with the attached patch. --- Peter Eisentraut wrote: > Am Mittwoch, 7. Februar 2007 11:24 schrieb Adriaan van Os: > > Section 9.9.1 of the Postgres docs > >

Re: [PATCHES] LIMIT/SORT optimization

2007-02-17 Thread Bruce Momjian
Is there a newer version of this patch? --- Gregory Stark wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > > On Wed, 2007-02-07 at 10:49 +, Gregory Stark wrote: > > > The two open issues (which are arguably the sa

Re: [PATCHES] [HACKERS] Dead code in _bt_split?

2007-02-17 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- He

Re: [PATCHES] patch for contrib/xml2

2007-02-17 Thread Bruce Momjian
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

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread Jeremy Drake
On Sat, 17 Feb 2007, Tom Lane wrote: > Jeremy Drake <[EMAIL PROTECTED]> writes: > > On Sat, 17 Feb 2007, Tom Lane wrote: > >> So I'd vote against complicating the API in order to make special > >> provision for these results. I claim that all we need is a function > >> taking (string text, patter

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread Tom Lane
Jeremy Drake <[EMAIL PROTECTED]> writes: > On Sat, 17 Feb 2007, Tom Lane wrote: >> So I'd vote against complicating the API in order to make special >> provision for these results. I claim that all we need is a function >> taking (string text, pattern text, flags text) and returning either >> arra

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread Mark Dilger
Jeremy Drake wrote: The regexp_split function code was based on some code that a friend of mine wrote which used PCRE rather than postgres' internal regexp support. I don't know exactly what his use-case was, but he probably had one because he wrote the function and had it returning SETOF text ;)

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread Jeremy Drake
Finally the voice of reason :) On Sat, 17 Feb 2007, Tom Lane wrote: > So I'd vote against complicating the API in order to make special > provision for these results. I claim that all we need is a function > taking (string text, pattern text, flags text) and returning either > array of text or se

Re: [PATCHES] \prompt for psql

2007-02-17 Thread Chad Wagner
On 2/17/07, Tom Lane <[EMAIL PROTECTED]> wrote: "Chad Wagner" <[EMAIL PROTECTED]> writes: > Would it make sense to say: > 1. if pset.notty is set and '-f' switch is not set then use simple_prompt > 2. else then use gets_fromFile(stdin) Actually, there's another issue, which is where to send th

Re: [PATCHES] \prompt for psql

2007-02-17 Thread Tom Lane
"Chad Wagner" <[EMAIL PROTECTED]> writes: > Would it make sense to say: > 1. if pset.notty is set and '-f' switch is not set then use simple_prompt > 2. else then use gets_fromFile(stdin) Actually, there's another issue, which is where to send the prompt. If we're using /dev/tty the answer is cle

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread Peter Eisentraut
Jeremy Drake wrote: > For this case see string_to_array: That only works with fixed delimiters, and I was hoping that regexp_split would be an alternative with regexp delimiters. It's certainly another argument that all the split functions in PostgreSQL should offer analogous interfaces. Ther

Re: [PATCHES] \prompt for psql

2007-02-17 Thread Chad Wagner
On 2/17/07, Tom Lane <[EMAIL PROTECTED]> wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: > stdin makes it impossible to read a script from stdin and still prompt > the user, but I think that is of limited usefulness. You can always get around that by reading the script with -f instead. On bala

Re: [PATCHES] \prompt for psql

2007-02-17 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > stdin makes it impossible to read a script from stdin and still prompt > the user, but I think that is of limited usefulness. You can always get around that by reading the script with -f instead. On balance I can see a lot more uses for read-from-stdin t

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > David Fetter wrote: >> What is it about having the whole match, pre-match and post-match >> available that you're objecting to? Are you saying there aren't >> common uses for any or all of these? Regular expression users use >> them all over the plac

Re: [PATCHES] \prompt for psql

2007-02-17 Thread Bruce Momjian
Magnus Hagander wrote: > Peter Eisentraut wrote: > > Bruce Momjian wrote: > >> Seems the consensus was this was a good idea, and not feature-creep. > > > > I wonder whether we want this to read from the console, like the > > password prompts, or from stdin. Not sure which is more useful. > > >

Re: [PATCHES] \prompt for psql

2007-02-17 Thread Magnus Hagander
Peter Eisentraut wrote: > Bruce Momjian wrote: >> Seems the consensus was this was a good idea, and not feature-creep. > > I wonder whether we want this to read from the console, like the > password prompts, or from stdin. Not sure which is more useful. > I think from stdin. Otherwise it won't

Re: [PATCHES] \prompt for psql

2007-02-17 Thread Chad Wagner
On 2/17/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote: Bruce Momjian wrote: > Seems the consensus was this was a good idea, and not feature-creep. I wonder whether we want this to read from the console, like the password prompts, or from stdin. Not sure which is more useful. Good point, I

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread Peter Eisentraut
David Fetter wrote: > What is it about having the whole match, pre-match and post-match > available that you're objecting to? Are you saying there aren't > common uses for any or all of these? Regular expression users use > them all over the place, You keep saying that, and I keep saying please

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread Jeremy Drake
On Sat, 17 Feb 2007, Peter Eisentraut wrote: > Jeremy Drake wrote: > > In case you haven't noticed, I am rather averse to making this return > > text[] because it is much easier in my experience to use the results > > when returned in SETOF rather than text[], > > The primary use case I know for s

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread David Fetter
On Sat, Feb 17, 2007 at 09:02:24AM +0100, Peter Eisentraut wrote: > Jeremy Drake wrote: > > In case you haven't noticed, I am rather averse to making this return > > text[] because it is much easier in my experience to use the results > > when returned in SETOF rather than text[], > > The primary

Re: [PATCHES] \prompt for psql

2007-02-17 Thread Peter Eisentraut
Bruce Momjian wrote: > Seems the consensus was this was a good idea, and not feature-creep. I wonder whether we want this to read from the console, like the password prompts, or from stdin. Not sure which is more useful. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---

Re: [PATCHES] patch adding new regexp functions

2007-02-17 Thread Peter Eisentraut
Jeremy Drake wrote: > In case you haven't noticed, I am rather averse to making this return > text[] because it is much easier in my experience to use the results > when returned in SETOF rather than text[], The primary use case I know for string splitting is parsing comma/pipe/whatever separate