[BUGS] BUG #7903: EAN13s are shown ISBN values
The following bug has been logged on the website: Bug reference: 7903 Logged by: Kurt Roeckx Email address: k...@roeckx.be PostgreSQL version: 9.2.3 Operating system: all Description: Hi, I was looking at the isn extention to store EAN13 value. A lot of those that I want to store are about books so they are also an ISBN13. My problem now is that I it's always displayed with the dashes in between, even when I want to show the EAN13. As far as I know EANs are never shown with the dashes. For EANs that aren't books it's also doing XXX-X-X, which I also don't want. For UPC it seems to do what I want. I think the output should depend on wheter I want to show an ISBN or EAN. Kurt -- 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 #8512: Can't use columns I can't read in the where clause of a select
The following bug has been logged on the website: Bug reference: 8512 Logged by: Kurt Roeckx Email address: k...@roeckx.be PostgreSQL version: 9.0.6 Operating system: Linux Description: Hi, When I read the documentation for GRANT, I see: SELECT Allows SELECT from any column, or the specific columns listed, of the specified table, view, or sequence. Also allows the use of COPY TO. This privilege is also needed to reference existing column values in UPDATE or DELETE. I read that as "SELECT field1 from table where field2 = 1" should work if I have grant select(field1), but not on field2. I'm getting a "permission denied". If I remove the where clause it of course works. I'm not sure if the behaviour is expected or not. Maybe I'm reading the documentation wrong, or maybe the documentation is just wrong. Could someone please clarify? Kurt -- 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 #5225: create table: cast necessary for constant??
The following bug has been logged online: Bug reference: 5225 Logged by: Kurt wagner Email address: kurt.wagnerext...@leoni.com PostgreSQL version: 8.41 Operating system: HP-UX Description:create table: cast necessary for constant?? Details: During migration from Informix to Postgres I came across following issue: create temp table temp1 as SELECT firmnr, werknr, 'I' as invper, invnum from ; the next select on table temp1 returned the error ERROR: failed to find conversion function from unknown to character [SQL State=XX000] I could find out that the column invper in the temp. table temp1 was defined as data type "unknown". To me it is a bug because the column is filled by a constant. So regardless if you estimate it as char, varchar, or text it is still processable whereas "unknown" is the worst case and returns an error as described above. other DBs (e.g. db2, or Informix) can handle such cases correctly. is it possible to fix it, please? -- 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 #5225: create table: cast necessary for constant??
Thanks Tom and Kevin for your detailed explanation. Even if I know now there is no chance of changing it I'd like you to consider following fact: when writing a character constant elsewhere then at first it is interpreted as character constant - right? then it is casted to the desired type e.g. SELECT... FROM ... WHERE now() > '2009-12-03' at first the input is accepted as character literal (@Tom: in no way the literal is automatically interpreted as a user defined data type) then the literal is casted to timestamp then it is compared. This behaviour you can see when typing a wrong timestamp: ERROR: invalid input syntax for type timestamp with time zone: "2009-12#03" [SQL State=22007] -> this is a message created by the data type casting setting the column type to unknown will deactivate all automatic type casts available. For me it was not logical (but errornous) to not interpret the literal as please refer to following statement: CREATE TEMP TABLE blabla AS SELECT now() AS timecol, 0 AS intcol, 0.0 AS deccol, 'I' AS CHARCOL FROM mytable; Postgres decided to define deccol as numeric even not knowing the exact type. But setting it to numeric it allows further processing. Only charcol is unknown which causes problems in further processing. you see what I mean? thank you and kind regards Kurt -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Thursday, December 03, 2009 12:40 AM To: Kevin Grittner Cc: Craig Ringer; Wagner, Kurt; pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #5225: create table: cast necessary for constant?? "Kevin Grittner" writes: > Quoting from section 5.3 of "WG3:HBA-003 H2-2003-305 August, 2003 > (ISO-ANSI Working Draft) Foundation (SQL/Foundation)": > | 13) The declared type of a is > | fixed-length character string. > Treating an otherwise unadorned set of characters between two > apostrophes as anything except a character string literal of type > CHARACTER with a length calculated per the above violates the > standard. Rather than pretending otherwise, we should be prepared > to explain the reasons for the deviation, describe what the > PostgreSQL behavior *is*, and justify the deviation. Sorry about that --- I had confused this case with that of a bare NULL literal, which Postgres treats the same as an unadorned string literal for type determination purposes. You're right that the spec treats them differently. This is feasible for the spec's purposes because it has such a paucity of data types. Also, I believe that the spec expects you to explicitly mark literals that aren't to be treated as plain strings, ie, in something like TIMESTAMP '2009-12-02 18:28:58' you're not really supposed to omit the word TIMESTAMP. Postgres has a whole lot of datatypes, including user-added ones, and most of them share the unadorned string literal as the base case for constants. Giving preference to CHARACTER would make that machinery a lot less pleasant to use. 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
[BUGS] BUG #5479: PosgreSQL Documentation does not mention OPEN
The following bug has been logged online: Bug reference: 5479 Logged by: Kurt wagner Email address: kurt.wag...@leoni.com PostgreSQL version: 8.4 Operating system: HP-UX Description:PosgreSQL Documentation does not mention OPEN Details: When checking the Web Site http://www.postgresql.org/docs/8.4/static/sql-commands.html I recognized that the commands "declare" and "close" are documented, but I failed to find "open". Could you please add it sometime? -- 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 #5747: TimeStamps too far into the future are invalid
The following bug has been logged online: Bug reference: 5747 Logged by: Kurt Stam Email address: ks...@apache.org PostgreSQL version: 8.3 Operating system: OSX Description:TimeStamps too far into the future are invalid Details: https://issues.apache.org/jira/browse/JUDDI-374 When the coverage period goes out too far postgres has issues. The coverage periods are specified in the uddi-tck-base module in the directory src/main/resources/uddi_data/subscription; the files subscriptionresults3.xml and subscriptionresults4.xml: Changing the endPoint from 2100 to 2030. This is clearly a bug in postgres or the postgres driver. On saving no error is thrown, however the endpoint field is set to 'invalid' which is an issue when the date is parsed back into a timedate. -- 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 #6133: -lpq frees unallocated memory on exit
The following bug has been logged online:
Bug reference: 6133
Logged by: Kurt Mielke
Email address: k...@it-pilots.com
PostgreSQL version: 8.4.8 + 9.0.4
Operating system: Centos X86_64 5.5 & 6.0
Description:-lpq frees unallocated memory on exit
Details:
x.c: is a very simple c-program:
main() { }
When compiled with
gcc -o x -lpq x.c
valgrind ./x
says "invalid free ... Address 0x4029508 is not stack'd, malloc'd or
(recently) free'd"
gcc -o x x.c
does not have this problem
I have tried linking with centos distribution developer versions and tried
making it from 8.4.2 8.4.8 9.0.4 tar balls, using configure with no options
The problem is the same - I found a posting from 2002 which I think is the
same problem, but I found no follow-ups.
I looked at make output to identify other libraries, which might be
responsible - but:
gcc -o x -lcrypt -ldl -lm -lpgport -lpgtypes -lpthread -lreadline -lz x.c
is OK, while linking with either -lpq or -lecpg will give you the valgrind
error.
On the two machines I tried it on I have:
gcc.x86_64 4.4.4-13.el6 / glibc.i686 2.12-1.7.el6_0.5
gcc.x86_64 4.1.2-50.el5 / glibc.i686 2.5-58.el5_6.4
And "Yes!" - the problem is also present if I do some real pg-lib, like
running testlibpq3.c - again there is one free too many.
--
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 #7836: COPY command does not honor 'FORMAT' option
The following bug has been logged on the website: Bug reference: 7836 Logged by: Kurt Lidl Email address: kurt.l...@cello.com PostgreSQL version: 9.2.2 Operating system: FreeBSD 9.1 (i386 - 32bit) Description: The COPY documentation says that with 9.1 (or newer), there is an option called "FORMAT", so the user can do "FORMAT binary". The old way just used a keyword "binary", and this way is supported for backwards compatibility. However, it doesn't appear that the "FORMAT" keyword works properly: psql -U pgsql template1 psql (9.2.2) Type "help" for help. template1=# copy pg_aggregate to '/tmp/agg.bin' with format binary; ERROR: syntax error at or near "format" LINE 1: copy pg_aggregate to '/tmp/agg.bin' with format binary; ^ template1=# copy pg_aggregate to '/tmp/agg.bin' with binary; COPY 120 -- 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 #7836: COPY command does not honor 'FORMAT' option
On 1/29/2013 3:19 PM, hubert depesz lubaczewski wrote: On Tue, Jan 29, 2013 at 06:20:05PM +, kurt.l...@cello.com wrote: template1=# copy pg_aggregate to '/tmp/agg.bin' with format binary; correct syntax: copy pg_aggregate to '/tmp/agg.bin' with (format 'binary'); Best regards, depesz Oops. Silly me. Thanks for pointing out my missing parens. -Kurt -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
