Re: [GENERAL] Development of cross-platform GUI for Open Source DBs

On 27.11.2006 17:36 Tony Caduto wrote: The closest to Delphi in a cross platform system is NetBeans and even with their form designer it's still tedious working with databases compared to Delphi. What about Lazarus? It claims to be cross-platform, but I don't know how it compares with regards

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/06 23:58, Harald Armin Massa wrote: > Ron, > >> >> > In the "real world" there is no such thing as a primary key. At least >> not >> > over time. Not enough people understand the concept of a primary key to >> > make those things existent in

Re: [GENERAL] Solaris 10 problem

This is exactly what i am doing. Sun Microsystems Inc. SunOS 5.10 Generic January 2005 You have new mail. # su - postgres Sun Microsystems Inc. SunOS 5.10 Generic January 2005 -bash-3.00$ id uid=49500(postgres) gid=65434(postgres) -bash-3.00$ initdb -D /var/lib/pgsql/data -bash: /usr

Re: [GENERAL] vacuum: out of memory error

On Nov 24, 2006, at 4:59 AM, Jakub Ouhrabka wrote: DETAIL: Failed on request of size 262143996. STATEMENT: VACUUM ANALYZE tablename There are few of them, always the same request size(?) but different two databases (out of 100+) and few different tables (pg_listener, pg_statistic and few s

Re: [GENERAL] SSL error: decryption failed or bad record mac

On Nov 27, 2006, at 12:06 PM, Claudio Rossi wrote: Hello, I just installed postgresql 8.1.5 and the only things I ported from 8.0.3 (last version I used) are server, user and CA X509 certificates (fresh install for everything else). I'm using OpenSSL 0.9.8d, Fedora Core 4, I have enabled SSL

Re: [GENERAL] A generic trigger to log chanes on database tables

On Nov 23, 2006, at 10:32 AM, Charles Ambrose wrote: Is there a way that I could create a trigger that logs the changes (updates, deletes) of a table? I mean, I want to put in a table the changes to any table in a database and also put in the table the column that was modified and the corres

Re: [GENERAL] Connecting via ssh tunnel

On Nov 24, 2006, at 2:56 PM, ben short wrote: I have a postgresql server setup on a Solaris 10 box. I can connect to the db via psql from the local machine. What I have been trying to do it connect with pgAdmin from my workstation. I have setup the tunnel correctly, local port 5432 and destinatio

Re: [GENERAL] IN clause

On Nov 24, 2006, at 9:04 AM, Marcus Engene wrote: There is one other case where I personally find nullable columns a good thing: process_me ish flags. When a row is not supposed to be processed that field is null and when a field is null it wont be in the index [at least on Oracle]. Actually, t

Re: [GENERAL] Editing contrib modules which are loaded by default?

Isn't there an option when you install on windows that controls what contrib stuff is included? Anyway, it's pretty simple to add plpgsql back in using CREATE LANGUAGE. On Nov 25, 2006, at 5:16 PM, novnov wrote: I hadn't checked and the page you pointed to here was different from the one

Re: [GENERAL] Solaris 10 problem

On Nov 27, 2006, at 8:59 AM, Doron Baranes wrote: I installed postgres 814 on solaris 10 using the following packages SUNWpostgr-libs-8.1.4-x86.tar.gz SUNWpostgr-8.1.4-x86.tar.gz SUNWpostgr-server-8.1.4-x86.tar.gz SUNWpostgr-server-data-8.1.4-x86.tar.gz SUNWpostgr-contrib-8.1.4-x86.tar.gz SUNWpos

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

Ron, > In the "real world" there is no such thing as a primary key. At least not > over time. Not enough people understand the concept of a primary key to > make those things existent in the real world. There are lots of numbers. Credit card numbers, account numbers sales ticket numbers, etc,

Re: [GENERAL] Why overlaps is not working

On Nov 23, 2006, at 10:57 AM, Richard Broersma Jr wrote: If my database contains dates greater than DATE '-12-31' then this check fails. This is why I'm searching for a real MAX_DATE value in Postgres. It would be nice if there will be MAX_DATE constant in Postgres or some one row sys

Re: [GENERAL] PostgreSQL doesn't accept connections when Windows

George, I guess your service is not running after rebooting? You can check this via services.msc This is what is confusing me - the service IS running after rebooting, but does not appear to be listening on port 5435. If I simply restart the service in the Administrative Tools > Component Serv

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Nov 23, 2006, at 10:23 AM, Ron Johnson wrote: I'm one of those who thinks that a (possibly multisegment) natural key *does* exist, and that if you think it doesn't, your design is wrong. I agree, but that doesn't mean you want to be spreading that multi- field key throughout your database.

Re: [GENERAL] NULLs ;-)

> But > > regression=# select (null = null) is unknown; > ?column? > -- > t > (1 row) > > which I think is not what you wanted. Right. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ---(end of broadcast)---

Re: [GENERAL] Question about encoding

> Is it possible to configure PostgreSQL so that a " LIKE 'a' " query > will match a 'á' value, ie, make it accent-insensitive ? I forgot this was possible using regular expressions. I don't think it is possible using the LIKE syntax. if you use something like: select * from yourtable where you

Re: [GENERAL] Connecting via ssh tunnel

On Monday 27 November 2006 02:38, Weerts, Jan wrote: > Hi all! > > [EMAIL PROTECTED] wrote: > > On Friday 24 November 2006 12:56, ben short wrote: > >> I have a postgresql server setup on a Solaris 10 box. I can > >> connect to the db via psql from the local machine. What I have > >> been trying to

Re: [GENERAL] How to increace nightly backup speed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/06 19:26, Glen Parker wrote: > Jeff Davis wrote: >> On Mon, 2006-11-27 at 19:13 +0200, Andrus wrote: >>> I need to create nightly backups to separate computer over internet >>> from 8.1 server >>> >>> I tried to run pg_dump to make backup usin

Re: [GENERAL] Connecting via ssh tunnel

Ok I have fixed it. My port fowarding was fine but i needed to set AllowTcpForwarding to yes in sshd_config. Ben On 11/27/06, Weerts, Jan <[EMAIL PROTECTED]> wrote: Hi all! [EMAIL PROTECTED] wrote: > On Friday 24 November 2006 12:56, ben short wrote: >> I have a postgresql server setup on a S

[GENERAL] Question about encoding

Is it possible to configure PostgreSQL so that a " LIKE 'a' " query will match a 'á' value, ie, make it accent-insensitive ? Thanks in advance, Daniel Serodio ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http:

Re: [GENERAL] which version? old user coming back....

On Sat, Nov 25, 2006 at 01:38:17PM -0800, [EMAIL PROTECTED] wrote: > > Look into Debian unstable, or if you are partial to Red Hat-derived > > stuff look into Fedora. > > I have and if it is there I can't find it. Where are you looking? http://packages.debian.org/unstable/misc/postgresql-7.4 htt

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Nov 28, 2006, at 9:55 , Joshua D. Drake wrote: On Tue, 2006-11-28 at 09:29 +0900, Michael Glaesemann wrote: On Nov 28, 2006, at 9:02 , Joshua D. Drake wrote: On Mon, 2006-11-27 at 17:31 -0600, John McCawley wrote: I promise I'm not trying to be a pain in the butt ;) Do you then use yo

Re: [GENERAL] How to increace nightly backup speed

Jeff Davis wrote: On Mon, 2006-11-27 at 19:13 +0200, Andrus wrote: I need to create nightly backups to separate computer over internet from 8.1 server I tried to run pg_dump to make backup using command "..\pg_dump\pg_dump.exe" -i -Z9 -b -v -f "C:\061127 mybackup.backup" -F c -h 81.50.12.18 -

Re: [GENERAL] NULLs ;-)

Scott Ribe <[EMAIL PROTECTED]> writes: > Well, actually, it would be: > a = b or (a = b) is unknown > But that certainly would more concise. But regression=# select (null = null) is unknown; ?column? -- t (1 row) which I think is not what you wanted. regards,

Re: [GENERAL] NULLs ;-)

> how about > > SELECT * > FROM > YOURTABLE > where > ( a = b ) IN UNKNOWN; Well, actually, it would be: a = b or (a = b) is unknown But that certainly would more concise. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ---

Re: [GENERAL] NULLs ;-)

--- Scott Ribe <[EMAIL PROTECTED]> wrote: > > (Can we talk about NULL next? :P) > > Seriously though, there is one thing I've been meaning to bring up. I > understand why NULLs compare the way they do in queries, and that's fine. > But there are times when I need to query what would be described

Re: [GENERAL] NULLs ;-)

> Check out IS DISTINCT FROM > > http://www.postgresql.org/docs/current/interactive/functions- > comparison.html > > I think that will help you. It's exactly what I was asking for. Well, except for the deja-vu feeling where I'm wondering if I didn't read that a long time ago and then forget it

Re: [GENERAL] NULLs ;-)

On Mon, 2006-11-27 at 17:37 -0700, Scott Ribe wrote: > > (Can we talk about NULL next? :P) Oh bring it on! :) Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive Postg

Re: [GENERAL] NULLs ;-)

Scott Ribe <[EMAIL PROTECTED]> writes: > But there are times when I need to query what would be described in > relational terms as "not known to be equal", and > where a <> b or (a is null and b is not null) or (a is not null and b is > null) IS DISTINCT FROM ? regards,

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Tue, 2006-11-28 at 09:29 +0900, Michael Glaesemann wrote: > On Nov 28, 2006, at 9:02 , Joshua D. Drake wrote: > > > On Mon, 2006-11-27 at 17:31 -0600, John McCawley wrote: > >> I promise I'm not trying to be a pain in the butt ;) Do you then use > >> your serial id as your foreign key in other

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Mon, 2006-11-27 at 17:22 -0700, Scott Ribe wrote: > >> I promise I'm not trying to be a pain in the butt ;) Do you then use > >> your serial id as your foreign key in other tables, or the > >> firstname/lastname primary key? > > > > Now that is a good question. I would use the id, but that is

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Mon, 2006-11-27 at 18:14 -0600, Ron Johnson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/27/06 17:25, Joshua D. Drake wrote: > > On Mon, 2006-11-27 at 17:09 -0600, John McCawley wrote: > [snip] > > users > > = > > id serial unique, > > first_name text, > > last_name te

Re: [GENERAL] Unexpected sort order.

On Mon, 2006-11-27 at 17:05 -0500, Tom Lane wrote: > Jeff Davis <[EMAIL PROTECTED]> writes: > > On Mon, 2006-11-27 at 12:44 -0800, Ron Mayer wrote: > >> Shouldn't the results of this query shown here been sorted by "b" rather > >> than by "a"? > > >> li=# select * from (select (random()*10)::int

Re: [GENERAL] NULLs ;-)

On Nov 28, 2006, at 9:37 , Scott Ribe wrote: (Can we talk about NULL next? :P) Seriously though, there is one thing I've been meaning to bring up. I understand why NULLs compare the way they do in queries, and that's fine. But there are times when I need to query what would be described in

Re: [GENERAL] postgresql bug

Best to always use the list as a resource, not individuals (since a person such as yourself would then be able to find the latest related issues when doing a web-search). I've cc-ed the general list on principle. The error I got had to do with a failing disk in a linux system. I have no clues a

[GENERAL] NULLs ;-)

> (Can we talk about NULL next? :P) Seriously though, there is one thing I've been meaning to bring up. I understand why NULLs compare the way they do in queries, and that's fine. But there are times when I need to query what would be described in relational terms as "not known to be equal", and

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Nov 28, 2006, at 9:02 , Joshua D. Drake wrote: On Mon, 2006-11-27 at 17:31 -0600, John McCawley wrote: I promise I'm not trying to be a pain in the butt ;) Do you then use your serial id as your foreign key in other tables, or the firstname/lastname primary key? Now that is a good questi

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

>> I promise I'm not trying to be a pain in the butt ;) Do you then use >> your serial id as your foreign key in other tables, or the >> firstname/lastname primary key? > > Now that is a good question. I would use the id, but that is not > technically proper :). But firstname/lastname is *NOT* a

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/06 17:25, Joshua D. Drake wrote: > On Mon, 2006-11-27 at 17:09 -0600, John McCawley wrote: [snip] > users > = > id serial unique, > first_name text, > last_name text, > primary key (first_name,last_name) > > Yes there are problems with th

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Mon, 2006-11-27 at 17:31 -0600, John McCawley wrote: > I promise I'm not trying to be a pain in the butt ;) Do you then use > your serial id as your foreign key in other tables, or the > firstname/lastname primary key? Now that is a good question. I would use the id, but that is not technic

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> A artificial does not protect against duplication. > > That's it, in a nut shell. There is no argument there. That is why you > don't use artificial keys. Sure, but in many cases natural primary keys simply do not exist. (People being the prime example.) Many examples of what are proposed as na

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

I promise I'm not trying to be a pain in the butt ;) Do you then use your serial id as your foreign key in other tables, or the firstname/lastname primary key? Joshua D. Drake wrote: users = id serial unique, first_name text, last_name text, primary key (first_name,last_name) Yes there

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Mon, 2006-11-27 at 17:09 -0600, John McCawley wrote: > This list represents the most informed database admins I know, and while > the conversation can easily devolve into minutae, I am genuinely > interested in everyone's opinions on this subject. Primary keys are a > pretty central aspect o

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

This list represents the most informed database admins I know, and while the conversation can easily devolve into minutae, I am genuinely interested in everyone's opinions on this subject. Primary keys are a pretty central aspect of database design, and most everyone on this list has unique ex

[GENERAL] CertFirst Legit?

I've been tasked with administering one of our PostgreSQL databases and know little or nothing about the product (though I do have DB experience). I've been looking for training and came across an administration class at 'http://www.postgresql.org/about/event.425' on the main web site. When I cal

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Mon, 2006-11-27 at 15:47 -0700, Scott Ribe wrote: > >>> insert a new address, and update the users table to the new address_id > >> > >> Which changes the user's "primary key". My point was that having the > >> address > >> id be part of the primary key is wrong. > > > > As I said, you don't

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

>>> insert a new address, and update the users table to the new address_id >> >> Which changes the user's "primary key". My point was that having the address >> id be part of the primary key is wrong. > > As I said, you don't *have* to do it that way. I was just giving an > example. You could jus

Re: [GENERAL] fatal error on 8.1 server

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tony Caduto wrote: >> I did not have autovacuum turned on and I usually do a vacuumdb -z -a -f >> -q each night but this one slipped through the cracks :-( > Strange -- autovacuum should have started an automatic database-wide > vacuum on that databas

Re: [GENERAL] Unexpected sort order.

Ron Mayer <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> It looks to me like the planner thinks that order by a and order by b >> are equivalent because the expressions are equal(); hence it discards >> what it thinks is a redundant second sort step. > Would it be a smaller waste of cycles and s

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Mon, 2006-11-27 at 14:36 -0700, Scott Ribe wrote: > > insert a new address, and update the users table to the new address_id > > Which changes the user's "primary key". My point was that having the address > id be part of the primary key is wrong. As I said, you don't *have* to do it that way.

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> Shenanigans! > > That problem occurs regardless of whether or not you use surrogate keys. > You have exceeded the scope of the example. Yes the "problem occurs" in that this is something that needs to be tracked, but the suggested schema presents peculiar problems for what otherwise is a pretty

Re: [GENERAL] fatal error on 8.1 server

Tony Caduto wrote: > Martijn van Oosterhout wrote: > >On Mon, Nov 27, 2006 at 02:22:19PM -0600, Tony Caduto wrote: > > > >>Just in case anyone is interested I did get it up and running with no > >>damage to the system. > >>It took well over a year for it to reach the 1 million threshold mark.

Re: [GENERAL] Unexpected sort order.

I wrote: > It looks to me like the planner thinks that order by a and order by b > are equivalent because the expressions are equal(); hence it discards > what it thinks is a redundant second sort step. > ... What's the use-case for sorting by a volatile > expression in the first place? It may be

Re: [GENERAL] Unexpected sort order.

Tom Lane wrote: > Jeff Davis <[EMAIL PROTECTED]> writes: >> On Mon, 2006-11-27 at 12:44 -0800, Ron Mayer wrote: >>> li=# select * from (select (random()*10)::int as a, (random()*10)::int as b >>> from generate_series(1,10) order by a) as x order by b; > >> It looks like a planner bug. > > It loo

Re: [GENERAL] fatal error on 8.1 server

Martijn van Oosterhout wrote: On Mon, Nov 27, 2006 at 02:22:19PM -0600, Tony Caduto wrote: Just in case anyone is interested I did get it up and running with no damage to the system. It took well over a year for it to reach the 1 million threshold mark. You mean one *billion*, right?

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

Shenanigans! That problem occurs regardless of whether or not you use surrogate keys. You have exceeded the scope of the example. -- Brandon Aiken CS/IT Systems Engineer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ribe Sent: Monday, November 27

Re: [GENERAL] Unexpected sort order (suspected bug)

Jeff Davis wrote: > On Mon, 2006-11-27 at 12:44 -0800, Ron Mayer wrote: >> Shouldn't the results of this query shown here been sorted by "b" rather >> than by "a"? >> >> I would have thought since "order by b" is in the outer sql statement it >> would have >> been the one the final result gets or

Re: [GENERAL] Unexpected sort order.

Jeff Davis <[EMAIL PROTECTED]> writes: > On Mon, 2006-11-27 at 12:44 -0800, Ron Mayer wrote: >> Shouldn't the results of this query shown here been sorted by "b" rather >> than by "a"? >> li=# select * from (select (random()*10)::int as a, (random()*10)::int as b >> from generate_series(1,10) or

Re: [GENERAL] fatal error on 8.1 server

On Mon, Nov 27, 2006 at 02:22:19PM -0600, Tony Caduto wrote: > Just in case anyone is interested I did get it up and running with no > damage to the system. > It took well over a year for it to reach the 1 million threshold mark. You mean one *billion*, right? That's one busy server! Hopeeful

Re: [GENERAL] Unexpected sort order.

On Mon, 2006-11-27 at 12:44 -0800, Ron Mayer wrote: > Shouldn't the results of this query shown here been sorted by "b" rather than > by "a"? > > I would have thought since "order by b" is in the outer sql statement it > would have > been the one the final result gets ordered by. > > li=# selec

Re: [GENERAL] backend crash following load command

"Merlin Moncure" <[EMAIL PROTECTED]> writes: > We are getting a backend crash after issueing a load command. No crash from your example here (on Fedora Core 5). What platform and gcc are you using exactly? Can you provide a stack trace from the crash? regards, tom lane

Re: [GENERAL] PostgreSQL doesn't accept connections when Windows

- Original Message - From: Harald Armin Massa Hi Harald, >I guess your service is not running after rebooting? You can check this via >services.msc This is what is confusing me - the service IS running after rebooting, but does not appear to be listening on port 5435. If I simply re

Re: [GENERAL] which version? old user coming back....

[EMAIL PROTECTED] wrote: >>> ...Should I expect >>> any problems with this even on the old 2.4 kernel? >> >> I'd advise you to be using a 2.6 kernel at this point, too. >> > ... I assume 8 will still work on 2.4 though. IIRC, you need a reasonably modern 2.6 kernel (early 2005) if you want fsync(

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> insert a new address, and update the users table to the new address_id Which changes the user's "primary key". My point was that having the address id be part of the primary key is wrong. Having it be a part of a key may be fine for many uses. But it's contrary to the notion of primary key that

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Mon, 2006-11-27 at 14:00 -0700, Scott Ribe wrote: > > You would update the address, the address id wouldn't change. If you > > want to keep track of old addresses you would keep an archive table > > associated with the user.id. > > But what about historical data that referenced the address? If

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> Right, but when you write your script (or whatever) that cleans these > keys up and does the merge, you're where you started -- arbitrary > integer keys with no meaning. If you merge databases where the keys are > *supposed* to have meaning, you then have to mangle *real* data to make > them mer

Re: [GENERAL] DB crashed

Thomas H. wrote: post some more informations, i.e. version, latest entries in logfile before crash, etc. - thomas - Original Message - *From:* rbaisak *To:* pgsql-general@postgresql.org *Sent:* Monday

[GENERAL] backend crash following load command

We are getting a backend crash after issueing a load command. It's pretty easy to recreate -- so easy that I'm not sure that there is something being overlooked. This is on pg 8.2 roughly two weeks old. Basic m.o. is: 1. create pic .so 2. load .so and call a function in it (from psql). 3. recom

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

Right, but when you write your script (or whatever) that cleans these keys up and does the merge, you're where you started -- arbitrary integer keys with no meaning. If you merge databases where the keys are *supposed* to have meaning, you then have to mangle *real* data to make them merge.

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> OK, let's use a synthetic key on the sales master table. In fact, > *both* companies have a synthetic key on their sales master tables. > > OMG, conflicting/overlapping synthetic keys! Which are not exposed in any UI and therefore easier to change? Heck, I'd use UUIDs everywhere if it wer

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> You would update the address, the address id wouldn't change. If you > want to keep track of old addresses you would keep an archive table > associated with the user.id. But what about historical data that referenced the address? If you move today, I still want to know where I shipped last week'

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

On Mon, 2006-11-27 at 13:38 -0700, Scott Ribe wrote: > > primary key (first_name,last_name,address_id) > > > > One will enable you to have a distinct Joshua Drake, one in portland > > oregon and one in portland maine. > > What happens when you move? Do we treat you as a different person? Or do we

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/06 14:34, Scott Ribe wrote: >> ...*most especially* when they are the only unique key. > > There are usually other keys which should be unique, and this should > certainly be reflected in the db design. On the other hand, designers should > n

[GENERAL] Unexpected sort order.

Shouldn't the results of this query shown here been sorted by "b" rather than by "a"? I would have thought since "order by b" is in the outer sql statement it would have been the one the final result gets ordered by. li=# select * from (select (random()*10)::int as a, (random()*10)::int as b f

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> primary key (first_name,last_name,address_id) > > One will enable you to have a distinct Joshua Drake, one in portland > oregon and one in portland maine. What happens when you move? Do we treat you as a different person? Or do we pretend that you've always lived in the same place? -- Scott R

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> ...*most especially* when they are the only unique key. There are usually other keys which should be unique, and this should certainly be reflected in the db design. On the other hand, designers should not strive to find and enforce combinations that won't actually necessarily be unique, such as

Re: [GENERAL] fatal error on 8.1 server

Alvaro Herrera wrote: Stop the postmaster, start a standalone backend, and issue a database-wide VACUUM on database postgres. Just in case anyone is interested I did get it up and running with no damage to the system. It took well over a year for it to reach the 1 million threshold mark. T

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> > Perhaps I am amazingly ignorant, but I have yet to find a case where my > > approach causes any real problems. What does using "real" data as a > > primary key buy you? The only real advantages I can see are that an > > individual record's data will be somewhat more human-readable without >

Re: [GENERAL] DB crashed

post some more informations, i.e. version, latest entries in logfile before crash, etc. - thomas - Original Message - From: rbaisak To: pgsql-general@postgresql.org Sent: Monday, November 27, 2006 8:26 PM Subject: [GENERAL] DB crashed I have been using postgres since a lo

Re: [GENERAL] Solaris 10 problem

One suggestion would be to not cross post to admin and general and answer the question sent back to you on the admin list, but that's just me. On Mon, Nov 27, 2006 at 04:59:22PM +0200, Doron Baranes wrote: > > Hi, > > I installed postgres 814 on solaris 10 using the following packages > SUNWp

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 27, 2006, at 1:21 PM, Brandon Aiken wrote: The other argument is that it's redundant data with no real meaning to the domain, meaning using surrogate keys technically violates low- order normal forms. It has real meaning in the sense that

[GENERAL] DB crashed

I have been using postgres since a long time. Recently number of users in my portal has been increased drastically and because of that load on Database server has been increased. Suddenly postgres Database crashed and I need to restart the DB. I am not able to find out root cause of this problem.

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

It's an arbitrary identifier that only has meaning within the context of the database. The domain model isn't supposed to model data in a database. It's supposed to model data which coincidentally is going to be stored in a database. As far as your bank's poor software design, I can't help you t

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/06 12:53, John McCawley wrote: > >> Yes, that's the point. They are legacy designs, and that portion of >> the design is wrong. >> >> >> > I'll weigh in my my .02 on this subject. After much pain and agony in > the real world, I have take

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/06 13:37, Scott Ribe wrote: >> In the real world, >> data changes, even supposedly unchangeable data. > > And that's the crux of it. All of the "that design is wrong" arguments in > the world won't stop data that has been constant & unique fo

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> There are lots of numbers. Credit card numbers, account numbers > sales ticket numbers, etc, etc ad nauseum. Julian day and Julian > date, even. You can't have lived in "the west" in the past 30 years > without being surrounded by them. > > It's their blind use in *every* table which I take

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/06 13:23, Harald Armin Massa wrote: > John, > > I'll weigh in my my .02 on this subject. After much pain and agony in >> the real world, I have taken the stance that every table in my database >> must have an arbitrary, numeric primary key (

Re: [GENERAL] fatal error on 8.1 server

On Mon, 2006-11-27 at 13:36 -0600, Tony Caduto wrote: > Alvaro Herrera wrote: > > Tony Caduto wrote: > > > >> I don't know what the exact version is but I am getting this: > >> > >> FATAL: database is not accepting commands to avoid wraparound data loss > >> in database "postgres" > >> > >> Ho

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

> In the real world, > data changes, even supposedly unchangeable data. And that's the crux of it. All of the "that design is wrong" arguments in the world won't stop data that has been constant & unique for decades from changing when some manager, rightly or wrongly, sees a "business need" for it

Re: [GENERAL] fatal error on 8.1 server

Alvaro Herrera wrote: Tony Caduto wrote: I don't know what the exact version is but I am getting this: FATAL: database is not accepting commands to avoid wraparound data loss in database "postgres" How can I recover from this and why woud this happen to the postgres database? Has my se

Re: [GENERAL] PostgreSQL doesn't accept connections when Windows Server is rebooted

George, I guess your service is not running after rebooting? You can check this via services.msc Most propable cause: the postgres user does not have logon_as_service privilege. I ran the installer logged in under an Administrator account, and set the service account to postgres. That is th

Re: [GENERAL] fatal error on 8.1 server

Tony Caduto wrote: > I don't know what the exact version is but I am getting this: > > FATAL: database is not accepting commands to avoid wraparound data loss > in database "postgres" > > How can I recover from this and why woud this happen to the postgres > database? Has my server been hacke

[GENERAL] fatal error on 8.1 server

I don't know what the exact version is but I am getting this: FATAL: database is not accepting commands to avoid wraparound data loss in database "postgres" How can I recover from this and why woud this happen to the postgres database? Has my server been hacked? there should be no inserts

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

John, I'll weigh in my my .02 on this subject. After much pain and agony in the real world, I have taken the stance that every table in my database must have an arbitrary, numeric primary key (generally autogenerated). I feel the same. In the "real world" there is no such thing as a primary

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

Simply put, it doesn't scale as well. If a table already has candidate keys, then you've presumably got unique indices on them. A surrogate primary key adds another segment of data to pass through I/O and another index to maintain. Under high loads, those extra cycles will cost you transactions

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

Yes, that's the point. They are legacy designs, and that portion of the design is wrong. I'll weigh in my my .02 on this subject. After much pain and agony in the real world, I have taken the stance that every table in my database must have an arbitrary, numeric primary key (generally au

Re: [GENERAL] PostgreSQL doesn't accept connections when Windows

George Weaver wrote: I then updated the postgresql.conf file with "listen_addresses = '*' and changed the port from 5432 (currently being used for a 7.3 server) to 5435. Have you tried setting the port back to default and see what happens? Is it possible for you to stop the 7.3 server for a

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/06 11:47, Scott Marlowe wrote: > On Thu, 2006-11-23 at 10:23, Ron Johnson wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 11/22/06 20:23, carter ck wrote: >>> Hi all, >>> >>> I am wonderring if it is a good practice to use

Re: [GENERAL] IS it a good practice to use SERIAL as Primary Key?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/06 11:26, Scott Ribe wrote: >> Bottom line: check digits are in SSNs > > Uhm, no they're not. And this is of course one of the huge problems with > SSNs. (Although not quite as bad as the fact that they're not strictly > unique. Yes, really,

AIX and getaddrinfo (was Re: [GENERAL] Upgrade problem)

Bill Kurland <[EMAIL PROTECTED]> writes: > I did a google search on AIX + getaddrinfo and found > http://lists.samba.org/archive/rsync/2002-April/002063.html > In that context the author says that adding the port number in > etc/services solved his problem with getaddrinfo. Interesting. I wonder

  1   2   >