[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 > 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 -t --pset=footer=off
> 3) No output is generated
> 4) run
> psql -U -t --pset=footer=off -x
> 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 http://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 http://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
