Re: [BUGS] BUG #7940: Auto increment issue
On Wed, Mar 13, 2013 at 4:01 AM, wrote: > Hi, > I'm using PostgreSQL 9.0.1 and driver PostgreSQL 9.0 JDBC4 and my OS > is Ubuntu.I'm using serial type for auto-incrementing column id in my table > everything works fine .when i stop my application and restart the > application its fine but when i backup DB and then restore it back manually > i'm inserting id column by myself during restoring...after restore If i > start the application, the id column doesn't start incrementing from maximum > value of id instead starts from begining (i.e., 1) and getting duplicate key > value violates unique constraint "smsserver_out_pkey" Detail: Key (id)=(1) > already exists till upto restored number of entries. ...what is the solution > to over come this issue ... [snip] > My Insert Query for restoring the database > INSERT INTO > smsserver_out(id,type,recipient,text,wap_url,wap_expiry_date,wap_signal,create_date,originator,encoding,status_report,flash_sms,src_port,dst_port,sent_date,ref_no,priority,status,errors,gateway_id) Well, you didn't specify how exactly you are backing up and restoring the table, although from the INSERT snippet you showed it looks like you're not using pg_dump. If you were using pg_dump, it would handle resetting the sequence behind smsserver_out.id to its value at the time of the dump. If you are using some other method to backup and reload the table, you will have to include a call to setval() to set a sane value for the sequence. For the record, reimplementing pg_dump is usually a bad idea. Josh -- 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 #7913: TO_CHAR Function & Turkish collate
Hi,
On Tue, 2013-03-05 at 13:08 -0500, Tom Lane wrote:
> > I think it's a bug that should be backpatched.
>
> Done. In addition to day/month names, I found that there were
> case-folding hazards for timezone abbreviations ('tz' format)
> and Roman numerals for numbers ('rn' format) ... though, curiously,
> not for Roman numerals for months.
Thanks!
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
signature.asc
Description: This is a digitally signed message part
[BUGS] Questions about PostgreSQL Setup License
Hello, I read on your website that PostgreSQL source code is free for use and modification, but in my case I am working on a project where we are generating our own setup and we would like to integrate PostgreSQL setup within it. Are we also allowed to do that ? Thanks in advance for your response, Yours sincerely, Aurélien DUBILLOT Ingénieur Développement Software System Engineering / Nantes THALES Services S.A.S
[BUGS] BUG #7943: plpgsql parsing bug
The following bug has been logged on the website:
Bug reference: 7943
Logged by: Rikard Pavelic
Email address: rik...@ngs.hr
PostgreSQL version: 9.2.1
Operating system: Windows 7
Description:
ERROR: "_t1" is not a scalar variable
LINE 12: for _i1, _i2, _t1, _t2, _t3, _b in select * from (
^
create type s as ("URI" text, x int);
create table t( i int, "some" s[]);
create view v as select i::text as "URI", i, "some" from t;
create table table_updated (i int, old v, new v);
--this works
select * from (
SELECT sq.i, sq.xx, cast(sq.old[xx] as s),
(select n from unnest(sq.new) n where n."URI" = sq.old[xx]."URI"),
sq.new[xx],
not exists(select o from unnest(sq.old) o where o."URI" =
sq.new[xx]."URI")
AND sq.new[xx]::text IS NOT NULL
FROM
(
SELECT
t.i,
(t.old)."some" AS old,
(t.new)."some" AS new,
unnest((SELECT array_agg(x) FROM generate_series(1,
CASE WHEN
coalesce(array_upper((t.old)."some", 1), 0) >
coalesce(array_upper((t.new)."some", 1),0) THEN array_upper((t.old)."some",
1) ELSE array_upper((t.new)."some", 1) END) x)) as xx
FROM "table_updated" t
) sq) sq
--this throws an error
create or replace function fast_select(out i int, out index int, out old s,
out s, out new s, out is_new bool) returns setof record as
$$
declare _old s[];
declare _new s[];
declare _i1 int;
declare _i2 int;
declare _t1 s;
declare _t2 s;
declare _t3 s;
declare _b bool;
begin
for _i1, _i2, _t1, _t2, _t3, _b in select * from (
SELECT sq.i, sq.xx, cast(sq.old[xx] as s),
(select n from unnest(sq.new) n where n."URI" = sq.old[xx]."URI"),
sq.new[xx],
not exists(select o from unnest(sq.old) o where o."URI" =
sq.new[xx]."URI")
AND sq.new[xx]::text IS NOT NULL
FROM
(
SELECT
t.i,
(t.old)."some" AS old,
(t.new)."some" AS new,
unnest((SELECT array_agg(x) FROM generate_series(1,
CASE WHEN
coalesce(array_upper((t.old)."some", 1), 0) >
coalesce(array_upper((t.new)."some", 1),0) THEN array_upper((t.old)."some",
1) ELSE array_upper((t.new)."some", 1) END) x)) as xx
FROM "table_updated" t
) sq) sq loop
i = _i1;
index = _i2;
old = _t1;
changed = _t2;
new = _t3;
is_new = _b;
return next;
end loop;
end
$$ language plpgsql;
--
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 #7942: Timestamp "19991231 240000" should not be out of range
The following bug has been logged on the website:
Bug reference: 7942
Logged by: Georg Kindermann
Email address: georg.kinderm...@gmx.at
PostgreSQL version: 9.1.8
Operating system: Debian Wheezy
Description:
select cast('19991231 24' as timestamp);
--Produces >ERROR: timestamp out of range<
select cast('2101 00' as timestamp);
--Works
--For other years both styles work e.g
select cast('19981231 24' as timestamp);
select cast('19990101 00' as timestamp);
--1999 to 2000 is no Leap second. Is there something other special? Thanks!
--
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] Questions about PostgreSQL Setup License
On 14 March 2013 16:42, DUBILLOT Aurelien wrote: > Are we also allowed to do that ? Why are you posting this to the -bugs mailing list? The answer is yes, though IANAL, and that does not constitute legal advice. However, there are a number of fairly prominent full commercial forks, so I think you're safe. -- Regards, Peter Geoghegan -- 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] Questions about PostgreSQL Setup License
On Thu, Mar 14, 2013 at 9:42 AM, DUBILLOT Aurelien wrote: > I read on your website that PostgreSQL source code is free for use and > modification, but in my case I am working on a project where we are > generating our own setup and we would like to integrate PostgreSQL setup > within it. This isn't really a bug, but... Yes. You are allowed to do that. Just include a file with the PostgreSQL license and copyright. This is how I did it for a derived work: """ Copyright (c) 2012-2013, Heroku All rights reserved. Portions are derived from the PostgreSQL Project. The copyright for those can be found in POSTGRES-COPYRIGHT. Otherwise, the license is as follows: """ The license I have chosen is afterwards. POSTGRES-COPYRIGHT is just a copy of the postgres COPYRIGHT file. (https://github.com/fdr/pg_logfebe/ if you are curious) -- fdr -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] ERROR: syntax error in tsquery - for high-unicode whitespace
hi
it was tested on 9.1 and 9.3. Interestingly - it worked without error in
8.2.
$ select to_tsquery('english', E'a\xe2\x80\x86a');
ERROR: syntax error in tsquery: "a a"
the 3-byte utf8 character is SIX-PER-EM SPACE (based on info from
http://www.fileformat.info/info/unicode/char/2006/index.htm)
Not sure what should happen with it, but generally I thought that
whitespace characters will get ignored (treated as separators) when
building tsquery.
It seems to work that way when building tsvector though:
$ select to_tsvector('english', E'a\xe2\x80\x86a');
to_tsvector
-
(1 row)
and for larger example:
$ select to_tsvector('english', E'depesz\xe2\x80\x86whatever');
to_tsvector
---
'depesz':1 'whatev':2
(1 row)
$ select to_tsquery('english', E'depesz\xe2\x80\x86whatever');
ERROR: syntax error in tsquery: "depesz whatever"
Best regards,
depesz
--
The best thing about modern society is how easy it is to avoid contact with it.
http://depesz.com/
--
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 #7942: Timestamp "19991231 240000" should not be out of range
georg.kinderm...@gmx.at writes:
> select cast('19991231 24' as timestamp);
> --Produces >ERROR: timestamp out of range<
Oddly enough, I just fixed that last week:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=542eeba26992305d872be699158cb3ab1c2be6e6
Weird how a bug can go unnoticed for ten years and then two people trip
over it at almost the same time.
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 #7943: plpgsql parsing bug
rik...@ngs.hr writes: > The following bug has been logged on the website: > Bug reference: 7943 > Logged by: Rikard Pavelic > Email address: rik...@ngs.hr > PostgreSQL version: 9.2.1 > Operating system: Windows 7 > Description: > ERROR: "_t1" is not a scalar variable > LINE 12: for _i1, _i2, _t1, _t2, _t3, _b in select * from ( >^ [ shrug ... ] It's right: _t1 is not a scalar variable. (It has the composite type s.) The reason this is problematic is that writing a composite variable as the target of a FOR IN SELECT loop is defined as assigning all the columns from the SELECT into fields of the composite variable. Which is not what you wanted to have happen there, even if we were to extend the definition to allow a mixture of scalar and composite variables in the target list. I'd suggest declaring a record variable and using that as the target. 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] ERROR: syntax error in tsquery - for high-unicode whitespace
hubert depesz lubaczewski writes:
> $ select to_tsquery('english', E'a\xe2\x80\x86a');
> ERROR: syntax error in tsquery: "aâa"
> the 3-byte utf8 character is SIX-PER-EM SPACE (based on info from
> http://www.fileformat.info/info/unicode/char/2006/index.htm)
AFAICS, that behavior is correct, if you're using a locale that reports
â as being whitespace. Compare
u8e=# select to_tsquery('english', E'a a');
ERROR: syntax error in tsquery: "a a"
You need an ampersand or something in there.
Or use plainto_tsquery().
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
