[BUGS] BUG #3922: Problems migrating databases.
The following bug has been logged online: Bug reference: 3922 Logged by: Maximiliano Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.6 Operating system: Debian 8.2 Description:Problems migrating databases. Details: I being working with RedHat 7.3 and PostgreSQL 7.3 and I migrated every single data to the operating system mentioned in the form (Debian 8.2) and the PostgreSQL 8.2. While I migrated the data I had no problems, but in PostgreSQL 7.3 I had the function varchareq and the system functioned perfectly, now that I have the 8.2 version this function is not functioning. I don't know what happened, I hope to recieve an answer soon. Thanks. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #3921: CREATE TABLE / INCLUDING INDEXES fails with permission denied
"Tom Lane" <[EMAIL PROTECTED]> writes: > 1. DefineIndex() treats an omitted tablespace clause differently from > explicitly specifying the tablespace that is the database's default: > if you explicitly specify the space then you must have permissions on > it, otherwise you don't need any. (This is the same behavior as in > DefineRelation incidentally.) Maybe this isn't such a hot idea, and > we should treat the two cases interchangeably? I always thought that was absolutely bizarre. Security should never depend on *how* you refer to an object. You should either have access to the object or not regardless of how you refer to it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3921: CREATE TABLE / INCLUDING INDEXES fails with permission denied
"Andrew Gilligan" <[EMAIL PROTECTED]> writes: > test=> CREATE TABLE t2 (LIKE t1 INCLUDING INDEXES); > ERROR: permission denied for tablespace pg_default How annoying :-(. We could work around this particular manifestation with a patch to make generateClonedIndexStmt() not set index->tableSpace if the source index is in the database's default tablespace. However, it seems to me there are a number of definitional oddities in this area, so I'm bouncing this over to -hackers for some discussion. 1. DefineIndex() treats an omitted tablespace clause differently from explicitly specifying the tablespace that is the database's default: if you explicitly specify the space then you must have permissions on it, otherwise you don't need any. (This is the same behavior as in DefineRelation incidentally.) Maybe this isn't such a hot idea, and we should treat the two cases interchangeably? 2. Because heap_create() replaces MyDatabaseTableSpace with zero before storing reltablespace into pg_class, it is impossible to tell after the fact whether a table or index was created with an explicit tablespace specification that happened to match the DB's default, or whether the tablespace clause was omitted. This seems inconsistent with point 1, if we decide to maintain the current behavior that the cases are not treated identically. However we can't just change this, because of the way that CREATE DATABASE works. 3. Should LIKE INCLUDING INDEXES even try to copy the source index's tablespace? It doesn't try to copy the table's tablespace. (However, the new table's tablespace can be specified elsewhere in the command, whereas there's noplace to put a per-index tablespace spec.) IIRC it was reported as a bug that LIKE didn't copy index tablespaces, and we just "fixed" that without much thought, but maybe the point needs more careful consideration. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3894: JDBC DatabaseMetaData.getTables is inconsistently case-sensitive with schema name
On Fri, 1 Feb 2008, Adam Hardy wrote: it seems to me from what you just said that PostgreSQL server and JDBC driver require the schema name to be lower case deliberately, and that any given name that is not all lower case is converted to lower case by the server or the driver. Am I correct? Anything that is not quoted is converted to lowercase. This is contrary to the SQL spec (it says to convert it to uppercase), but that's unlikely to change anytime soon. A JDBC app can portably detect this case by checking DatabaseMetaData.storesLowerCaseIdentifiers() and adjusting the other metadata calls appropriately. Kris Jurka ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #3921: CREATE TABLE / INCLUDING INDEXES fails with permission denied
The following bug has been logged online: Bug reference: 3921 Logged by: Andrew Gilligan Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 Operating system: FreeBSD 4.11 Description:CREATE TABLE / INCLUDING INDEXES fails with permission denied Details: Hi all, There seems to be an incorrect permission failure if INCLUDING INDEXES is specified while creating a table, even if the user owns the database. The example below was run on 8.3.0 cvs, checked out earlier today. No changes were made to any tablespaces. template1=# CREATE USER andy PASSWORD 'foo'; CREATE ROLE Time: 2.350 ms template1=# CREATE DATABASE test OWNER andy; CREATE DATABASE Time: 225.004 ms template1=# \c test andy Password for user andy: You are now connected to database "test" as user "andy". test=> CREATE TABLE t1 (a int PRIMARY KEY); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "t1_pkey" for table "t1" CREATE TABLE Time: 25.515 ms test=> CREATE TABLE t2 (LIKE t1 INCLUDING INDEXES); ERROR: permission denied for tablespace pg_default test=> \db+ List of tablespaces Name| Owner | Location | Access privileges | Description +---+--+---+- pg_default | pgsql | | | pg_global | pgsql | | | (2 rows) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3894: JDBC DatabaseMetaData.getTables is inconsistently case-sensitive with schema name
I think my message below didn't get through, according to error notifications
from [EMAIL PROTECTED]
Hopefully this will be successful. See copy below.
Kris Jurka on 23/01/08 08:51, wrote:
On Tue, 22 Jan 2008, Adam Hardy wrote:
The following bug has been logged online:
Bug reference: 3894
Description:JDBC DatabaseMetaData.getTables is inconsistently
case-sensitive with schema name
Details:
create schema DEV;
but then DatabaseMetaData.getTables(null, "DEV", "%", new String[]
{"TABLE"}) returned an empty resultset.
However giving it the schema name "dev" returns the full resultset.
This is by design. While SQL provides case folding and quoting rules
those are not the same as the JDBC driver's rules. In SQL an unquoted
identifier is case folded while quoted identifiers are not. To
provide the most straightforward mapping for the JDBC driver, we
require an exact match because quoting in Java String objects isn't
the same as SQL. It would be odd to say getTable(..., "\"Dev\"",...)
to imply that you wanted a case sensitive match. Even odder would it
be to do a search for a schema with a quote in it's name using SQL
identifier rules in Java code.
Kris Jurka
Hi Kris,
it seems to me from what you just said that PostgreSQL server and JDBC
driver require the schema name to be lower case deliberately, and that
any given name that is not all lower case is converted to lower case by
the server or the driver. Am I correct?
Thanks
Adam
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[BUGS] BUG #3920: sequence not generated for postgres using toplink jpa
The following bug has been logged online: Bug reference: 3920 Logged by: Arun Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2 Operating system: Win XP Description:sequence not generated for postgres using toplink jpa Details: sequence not generated for postgres using toplink jpa This sequence generator code is not working properly @SequenceGenerator(name="catalog_seq_gen", sequenceName="catalog_seq", allocationSize=1) @Id @GeneratedValue(strategy = GenerationType.SEQUENCE,generator = "catalog_seq_gen") @Column(name ="catalog_id", nullable = false) private Long catalogId; @Column(name = "CATALOG_NAME", nullable = false) private String catalogName; @Column(name = "CATALOG_DESC") private String catalogDesc; I have 3 fields in the code and toplink is generating the query wrongly Exception in thread "main" javax.persistence.PersistenceException: javax.persistence.PersistenceException: Exception [TOPLINK-4002] (Oracle TopLink Essentials - 2.0 (Build SNAPSHOT (06/04/2007))): oracle.toplink.essentials.exceptions.DatabaseException Internal Exception: org.postgresql.util.PSQLException: ERROR: null value in column "catalog_id" violates not-null constraint Error Code: 0 Call: INSERT INTO CATALOG (CATALOG_NAME, CATALOG_DESC) VALUES (?, ?) bind => [Description, null] ideally it should generate INSERT INTO CATALOG (CATALOG_ID, CATALOG_NAME, CATALOG_DESC) VALUES (?,?, ?) bind => [1, Description, null] I am using Oracle TopLink 11g: Technical Preview 3 what could be the reason? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #3919: Service Privileges Bug
The following bug has been logged online: Bug reference: 3919 Logged by: Sergey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3RC2 Operating system: Windows 2003 SP2 Description:Service Privileges Bug Details: Postgre can't run under restricted user's account. Even if: 1) All 'service' rights to that account granted; 2) All 'disk' rights also granted (checked very carefully, '/data' in full access, other dirs read and execute); The error is 'Error 5 : Access denied'. Changing the user to 'Local Service' solves the issue. p.s. Postgre 8.2 on the same machine under restricted user with same priveleges running quite. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
