Re: [BUGS] Instalation !
"Rodrigo Ferraz" <[EMAIL PROTECTED]> writes: > Olá ! > > Preciso instalar o PostgreSql beta 8 para Windows em um computador Windows 2000 > server. Este computador é um controlador de comínio e não possui conta de > usuário local. Como faço para instalar sem um usuário administrador local?? > > Obrigado pela atenção. > > Rodrigo Translating for the maling list: == Hi! I need to install PostgreSQL 8 on a Windows 2000 Server. This is a domain controller and has no local user accounts available. How do I make the installation without a local administrator? Thanks for your attention. Rodrigo. == Be seeing you, -- Godoy. <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] Instalation !
> > Olá ! > > > > Preciso instalar o PostgreSql beta 8 para Windows em um computador > > Windows 2000 server. Este computador é um controlador de > comínio e não > > possui conta de usuário local. Como faço para instalar sem > um usuário administrador local?? > > > > Obrigado pela atenção. > > > > Rodrigo > > Translating for the maling list: > > == > Hi! > > > I need to install PostgreSQL 8 on a Windows 2000 Server. > This is a domain controller and has no local user accounts > available. How do I make the installation without a local > administrator? > > > Thanks for your attention. > > Rodrigo. > == There is no problem using a domain account instead of a local account. If you get the new installer (released yesterday - beta3dev1), it defaults to this on Domain Controllers. Just make sure the account is *not* an administrator. You can use any Domain Administrator account to start the installation, but the service account for pgsql has to be non-administrator. //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] configure does not catch --enable-bogosity
Noticed this when I had a typo on the configure command line. The configure script does not catch the following bogus option: --enable-bogosity That might seem like no biggie, but it also doesn't seem to notice this error: --enable-thread-safeyt (notice the mispelling) Makes it look like you had a valid configure. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] configure does not catch --enable-bogosity
"Ed L." <[EMAIL PROTECTED]> writes: > Noticed this when I had a typo on the configure command line. The configure > script does not catch the following bogus option: > --enable-bogosity Complain to the Autoconf project. They strenuously insist this is not a bug, and have done so for many years. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] [Slony1-general] Thread-safety detection on HP-UX
Clean build of pgsql 7.4.5 on HPUX B.11.23 on ia64 with --enable-thread-safety fails ... :( $uname -a HP-UX ... B.11.23 U ia64 0144848471 unlimited-user license $cd postgresql-7.4.5 $./configure --enable-thread-safety --without-readline --without-zlib ... checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes configure: error: Cannot enable threads on your platform. Please report your platform threading info to the PostgreSQL mailing lists so it can be added to the next release. Report all compile flags, link flags, functions, or libraries required for threading support. See the comment at the top of src/port/thread.c for more information. $gcc --version gcc (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] AT TIME ZONE INTERVAL and prepared statements
AT TIME ZONE INTERVAL $1 doesn't seem to be supported in prepared statements. This works: SELECT now() AT TIME ZONE INTERVAL '-08:00'; This doesn't: PREPARE mys(text) AS SELECT now() AT TIME ZONE INTERVAL $1; ERROR: syntax error at or near "$1" at character 57 These work: PREPARE mys(interval) AS SELECT now() AT TIME ZONE $1; PREPARE mys(text) AS SELECT now() AT TIME ZONE ($1::interval) Any reason why the second case doesn't work? Kris Jurka ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] AT TIME ZONE INTERVAL and prepared statements
Kris Jurka <[EMAIL PROTECTED]> writes: > AT TIME ZONE INTERVAL $1 doesn't seem to be supported in prepared > statements. Try AT TIME ZONE $1 or possibly AT TIME ZONE $1::interval You are confusing the syntax for a typed literal with part of the AT TIME ZONE construct. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] Problem with rule and null value
This is a resent. Wrong email account the first time. --- I'm using PostgreSQL 7.3.4. I've set up a series of rules and triggers to complete an intermediate table with similar informations from another table. This ensures better performance over a solution with views. Intermediate table: Table album_edit Field Type Length Not NullDefault alb_id int44 Yes ed_ref varchar30 Yes isbn varchar30 No flags int22 No pls_id int44 No A set of rules is added to another table, "album". The general principle of the relation between "album" and "album_edit", is that each record of "album" is duplicated in "album_edit" (and these record are uniquely identified in "album_edit" with the use of column "ed_ref"). So insert, update and delete on "album" are passed to "album_edit". One of the update rules is this one: CREATE OR REPLACE RULE albed_updalb3_rl AS ON UPDATE TO album WHERE new.pls_id != old.pls_id DO UPDATE album_edit SET pls_id=new.pls_id WHERE alb_id=new.id; It works until new.pls_id or old.pls_id is null. The rule is still called (based on my test), but the "DO" query is not executed correctly. The values in "album_edit" are not updated. To find the source of the problem I've modified the rule: CREATE OR REPLACE RULE albed_updalb3_rl AS ON UPDATE TO album WHERE new.pls_id != old.pls_id DO select old.pls_id, new.pls_id; Is this a bug or an intended behavior ? Here is a log with some tests. -- bd=# CREATE OR REPLACE RULE albed_updalb3_rl AS ON UPDATE TO album WHERE new.pls_id != old.pls_id DO select old.pls_id, new.pls_id; CREATE RULE bd=# update album set pls_id='666' where id='8838'; pls_id | pls_id + 100 |666 (1 row) bd=# update album set pls_id=null where id='8838'; pls_id | pls_id + (0 rows) bd=# update album set pls_id='666' where id='8838'; pls_id | pls_id + (0 rows) bd=# update album set pls_id='111' where id='8838'; pls_id | pls_id + 666 |111 (1 row) bd=# update album set pls_id='0' where id='8838'; pls_id | pls_id + 111 | 0 (1 row) bd=# update album set pls_id='111' where id='8838'; pls_id | pls_id + 0 |111 (1 row) bd=# update album set pls_id=null where id='8838'; pls_id | pls_id + (0 rows) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] AT TIME ZONE INTERVAL and prepared statements
On Fri, 22 Oct 2004, Tom Lane wrote: > You are confusing the syntax for a typed literal with part of the AT > TIME ZONE construct. Could you explain what the difference is between a typed literal "int '11'" and a cast(ed) literal "'11'::int" to me they seem like the same thing. Kris Jurka ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] AT TIME ZONE INTERVAL and prepared statements
Kris Jurka <[EMAIL PROTECTED]> writes: > On Fri, 22 Oct 2004, Tom Lane wrote: >> You are confusing the syntax for a typed literal with part of the AT >> TIME ZONE construct. > Could you explain what the difference is between a typed literal > "int '11'" and a cast(ed) literal "'11'::int" to me they seem like the > same thing. Yes, they are semantically the same. The first one is a kluge that Tom Lockhart put in to approximate the SQL spec's demands for representation of timestamp and interval constants. It does not work syntactically to try to extend it to a general cast construct (we can only barely manage to support it as-is --- there are various special cases that don't work such as arrays and qualified type names, and a depressingly large part of gram.y is devoted to getting the cases that do work to work). Even if we could get the parser to cope with that without reduce/reduce errors, we'd be greatly reducing the grammar's ability to detect actual syntax errors, because practically anything next to practically anything else would become a potentially legal cast construct. So, no "INTERVAL $1". Bad enough we have to take "INTERVAL 'string'". This wasn't one of the SQL committee's better ideas. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Problem with rule and null value
Marc Boucher <[EMAIL PROTECTED]> writes: > CREATE OR REPLACE RULE albed_updalb3_rl AS >ON UPDATE TO album WHERE new.pls_id != old.pls_id > DO >UPDATE album_edit SET pls_id=new.pls_id WHERE alb_id=new.id; > It works until new.pls_id or old.pls_id is null. The rule is still called > (based on my test), but the "DO" query is not executed correctly. That's not a bug. "foo != NULL" does not yield true, it yields NULL. You could test for nulls with IS NULL, or possibly use the IS DISTINCT FROM construct (does 7.3 have that? I forget.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
