[BUGS] BUG #8440: sevices not started automatically
The following bug has been logged on the website: Bug reference: 8440 Logged by: Jitendra Sabat Email address: sabat.jitendr...@gmail.com PostgreSQL version: Unsupported/Unknown Operating system: Window server 2012 Description: Currently i am running postgres8.3 but its services is not started automatically when I start the system. I have tried manually start everyday. But sometime it stopped automatically. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8441: Recursive function in plpgsql does not seem to handle null values correctly
The following bug has been logged on the website: Bug reference: 8441 Logged by: Tom van Ees Email address: tv...@davincigroep.nl PostgreSQL version: 9.0.4 Operating system: Windows Server 2008 R2 Description: The Levenshtein function can only handle strings with length 255 or less. I needed a Levenshtein function that could handle longer strings. Therefore I wrote the following udf: CREATE OR REPLACE FUNCTION longlevenshtein (string1 character varying (100), string2 character varying (100)) RETURNS integer AS $$ BEGIN IF (length(coalesce($1, '')) = 0 AND length(coalesce($2, '')) = 0) THEN RETURN 0; ELSEIF ($1 IS NULL and $2 IS NOT NULL and length($2) 0) THEN RETURN length($2); ELSEIF ($2 IS NULL and $1 IS NOT NULL and length($1) 0) THEN RETURN length($1); ELSEIF length($1) = 0 AND length(coalesce($2, '')) 0 THEN RETURN length(coalesce($2, '')); ELSEIF length($1) 0 AND (length($2) = 0 or $2 is null) THEN RETURN length(coalesce($1, '')); ELSE RETURN (Levenshtein(SUBSTRING($1 FROM 1 FOR 254), SUBSTRING($2 FROM 1 for 254)) + longlevenshtein(coalesce(SUBSTRING($1 FROM 255), ''), coalesce(SUBSTRING($2 FROM 255), ''))); END IF; END; $$ LANGUAGE plpgsql; When I invoke this function with SELECT longlevenshtein(null, 'foobar') I get a ERROR: stack depth limit exceeded while I expected the return value 6 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8441: Recursive function in plpgsql does not seem to handle null values correctly
Hello it works on 9.1.9 postgres=# SELECT longlevenshtein(null, 'foobar'); longlevenshtein - 6 Regards Pavel P.S. unlimitted varchar is text type in Postgres 2013/9/9 tv...@davincigroep.nl The following bug has been logged on the website: Bug reference: 8441 Logged by: Tom van Ees Email address: tv...@davincigroep.nl PostgreSQL version: 9.0.4 Operating system: Windows Server 2008 R2 Description: The Levenshtein function can only handle strings with length 255 or less. I needed a Levenshtein function that could handle longer strings. Therefore I wrote the following udf: CREATE OR REPLACE FUNCTION longlevenshtein (string1 character varying (100), string2 character varying (100)) RETURNS integer AS $$ BEGIN IF (length(coalesce($1, '')) = 0 AND length(coalesce($2, '')) = 0) THEN RETURN 0; ELSEIF ($1 IS NULL and $2 IS NOT NULL and length($2) 0) THEN RETURN length($2); ELSEIF ($2 IS NULL and $1 IS NOT NULL and length($1) 0) THEN RETURN length($1); ELSEIF length($1) = 0 AND length(coalesce($2, '')) 0 THEN RETURN length(coalesce($2, '')); ELSEIF length($1) 0 AND (length($2) = 0 or $2 is null) THEN RETURN length(coalesce($1, '')); ELSE RETURN (Levenshtein(SUBSTRING($1 FROM 1 FOR 254), SUBSTRING($2 FROM 1 for 254)) + longlevenshtein(coalesce(SUBSTRING($1 FROM 255), ''), coalesce(SUBSTRING($2 FROM 255), ''))); END IF; END; $$ LANGUAGE plpgsql; When I invoke this function with SELECT longlevenshtein(null, 'foobar') I get a ERROR: stack depth limit exceeded while I expected the return value 6 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8441: Recursive function in plpgsql does not seem to handle null values correctly
Hi, On 2013-09-09 17:26:48 +0200, Pavel Stehule wrote: it works on 9.1.9 That's probably a question of the configured/detected max_stack_depth. I have quite some doubts such a naive implementation implemented in plgsql will work for strings 255 chars in sensible manner though. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8441: Recursive function in plpgsql does not seem to handle null values correctly
tv...@davincigroep.nl writes: CREATE OR REPLACE FUNCTION longlevenshtein (string1 character varying (100), string2 character varying (100)) RETURNS integer AS $$ BEGIN IF (length(coalesce($1, '')) = 0 AND length(coalesce($2, '')) = 0) THEN RETURN 0; ELSEIF ($1 IS NULL and $2 IS NOT NULL and length($2) 0) THEN RETURN length($2); ELSEIF ($2 IS NULL and $1 IS NOT NULL and length($1) 0) THEN RETURN length($1); ELSEIF length($1) = 0 AND length(coalesce($2, '')) 0 THEN RETURN length(coalesce($2, '')); ELSEIF length($1) 0 AND (length($2) = 0 or $2 is null) THEN RETURN length(coalesce($1, '')); ELSE RETURN (Levenshtein(SUBSTRING($1 FROM 1 FOR 254), SUBSTRING($2 FROM 1 for 254)) + longlevenshtein(coalesce(SUBSTRING($1 FROM 255), ''), coalesce(SUBSTRING($2 FROM 255), ''))); END IF; END; $$ LANGUAGE plpgsql; When I invoke this function with SELECT longlevenshtein(null, 'foobar') I get a ERROR: stack depth limit exceeded Worksforme. You sure you transcribed the function accurately? Note however that sufficiently long input strings *will* drive this function to stack overrun, if you don't run out of heap memory first (I think the heap consumption will be O(N^2) ...). Consider rewriting it with a loop rather than recursion. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7817: psql does not relate to footer settings in extended mode
On Sun, Jan 20, 2013 at 10:33:37AM +, emes...@redhat.com wrote:
The following bug has been logged on the website:
Bug reference: 7817
Logged by: Eli Mesika
Email address: emes...@redhat.com
PostgreSQL version: 9.1.7
Operating system: Fedora 16
Description:
psql does not relate to footer settings in extended mode
Sometimes we need to run a sql command withot generating header and footer.
This can be done using the -t flag and --pset=footer=off
The problem is that the footer is still diaplyed even if it was set to off
if we use the extended mode for the query (-x flag)
Steps to Reproduce:
1) create a table without any data
for example
create table text(i int);
2) run
psql -U user -t --pset=footer=off db
3) No output is generated
4) run
psql -U user -t --pset=footer=off -x db
5) Output generated : (No Rows)
Actual results:
psql does not honour the footer settings when output is defined to be in
Extended Mode
Expected results:
psql should not generate any output is query has no results and -t and
--pset=footer=off were given
This has been fixed in PG 9.3 (released today) for the specific options
you supplied:
$ psql -t --pset=footer=off test
Default footer is off.
psql (9.4devel)
Type help for help.
CREATE TABLE test (x INT);
CREATE TABLE
SELECT * FROM test;
\x
Expanded display is on.
SELECT * FROM test;
Unfortunately, this did not fix the more simple case where
--pset=footer=off is specified, but not -t:
$ psql --pset=footer=off test
Default footer is off.
psql (9.4devel)
Type help for help.
CREATE TABLE test (x INT);
CREATE TABLE
SELECT * FROM test;
x
---
\x
Expanded display is on.
SELECT * FROM test;
-- (No rows)
The attached patch fixes this, and makes it match the rest of the output
formats, which do honor --pset=footer=off alone for footers.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/bin/psql/print.c b/src/bin/psql/print.c
new file mode 100644
index 5589cea..736225c
*** a/src/bin/psql/print.c
--- b/src/bin/psql/print.c
*** print_aligned_vertical(const printTableC
*** 1171,1177
if (cont-cells[0] == NULL cont-opt-start_table
cont-opt-stop_table)
{
! if (!opt_tuples_only)
fprintf(fout, _((No rows)\n));
return;
}
--- 1171,1177
if (cont-cells[0] == NULL cont-opt-start_table
cont-opt-stop_table)
{
! if (!opt_tuples_only cont-opt-default_footer)
fprintf(fout, _((No rows)\n));
return;
}
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7824: documentation bug: Extract DOW
On Tue, Jan 22, 2013 at 08:40:30PM +, tim.rom...@yahoo.com wrote: The following bug has been logged on the website: Bug reference: 7824 Logged by: Tim Romano Email address: tim.rom...@yahoo.com PostgreSQL version: 9.2.2 Operating system: Windows 7 x64 Description: Documentation seems to indicate that only a Timestamp value is a valid argument to the Extract function when trying to get the DOW, but a Date also works: dow The day of the week (0 - 6; Sunday is 0) (for timestamp values only) SELECT EXTRACT(DOW FROM TIMESTAMP '2001-02-16 20:38:40'); Result: 5 [Sorry for the late reply.] I assume you mean: SELECT EXTRACT(DOW FROM DATE '2001-02-16'); date_part --- 5 (1 row) That does work fine, and is documented in PG 9.2: http://www.postgresql.org/docs/9.2/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT The extract function retrieves subfields such as year or hour from date/time values. source must be a value expression of type timestamp, -- time, or interval. (Expressions of type date are cast to timestamp and -- can therefore be used as well.) Where did you see that DATE is not supported for EXTRACT? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
