On Thu, Feb 9, 2012 at 2:10 PM, David Salisbury wrote:
>
>
> On 2/9/12 10:08 AM, Rich Shepard wrote:
>
>> I have reports containing macroinvertebrate collection data for several
>> hundred (or several thousand) of taxa. There is no natural key since there
>> are multiple rows for each site/date
On Thursday, February 09, 2012 5:18:19 pm David Salisbury wrote:
> On 2/9/12 5:25 PM, Rich Shepard wrote:
> > For water quality data the primary key is (site, date, param) since
> > there's only one value for a given parameter collected at a specific
> > site on
> > a single day. No surrogate key n
On 2/9/12 5:25 PM, Rich Shepard wrote:
For water quality data the primary key is (site, date, param) since
there's only one value for a given parameter collected at a specific
site on
a single day. No surrogate key needed.
Yea. I was wondering if the surrogate key debate really boils down to
On Thu, 9 Feb 2012, Merlin Moncure wrote:
If you can't (which happens on various type of data), then the surrogate
is giving the illusion of row uniqueness when there isn't one.
Ah, but each row is unique. However, there is no consisten set of non NULL
values that can consistently define a u
On Thu, 9 Feb 2012, David Salisbury wrote:
Interesting. I used to think natural keys were okay, but have since decided
that surrogates are the way to go. That second layer of abstraction allows
for much easier data modifications when needed. What would be an example
of a natural key that woul
On 02/09/12 2:38 PM, Daniel Vázquez wrote:
YES /etc/sysconfig/pgsql/postgresql-9.1
I'm using /etc/sysconfig/pgsql/postgresql like in 8.4 ... my fault ...
is like some overunderstand ... but no doc about it.
whatever the name of the /etc/init.d/postgres** script is, it uses that
same name
Thanks Tom.
I get it. Putting it in another way, if there was a function and a VIEW and
this field name were to be changed, then we'd have a broken function
anyway.
The only issue is that (before writing this mail) I expected that a VIEW
would either throw up errors or would work without fail reg
THX all !!
My fault is I set the $PGDATA enviroment variable in
/etc/sysconfig/pgsql/**postgresql
like usual in 8.4
renaming the file to postgresql-9.1 solve the isue.
Thanks guys!
El 9 de febrero de 2012 22:25, Daniel Vázquez escribió:
> Hi!
>
> I've set my PGDATA variable in profile
> export P
On 2/9/2012 4:20 PM, Andy Colson wrote:
On 2/9/2012 4:10 PM, David Salisbury wrote:
On 2/9/12 10:08 AM, Rich Shepard wrote:
I have reports containing macroinvertebrate collection data for several
hundred (or several thousand) of taxa. There is no natural key since
there
are multiple rows for
On Thu, Feb 9, 2012 at 4:20 PM, Andy Colson wrote:
> On 2/9/2012 4:10 PM, David Salisbury wrote:
>>
>>
>>
>> On 2/9/12 10:08 AM, Rich Shepard wrote:
>>>
>>> I have reports containing macroinvertebrate collection data for several
>>> hundred (or several thousand) of taxa. There is no natural key si
On 2/9/2012 4:10 PM, David Salisbury wrote:
On 2/9/12 10:08 AM, Rich Shepard wrote:
I have reports containing macroinvertebrate collection data for several
hundred (or several thousand) of taxa. There is no natural key since
there
are multiple rows for each site/date pair. Years ago Joe Celko
On 2/9/12 10:08 AM, Rich Shepard wrote:
I have reports containing macroinvertebrate collection data for several
hundred (or several thousand) of taxa. There is no natural key since there
are multiple rows for each site/date pair. Years ago Joe Celko taught me to
seek natural keys whenever th
On 02/09/12 1:25 PM, Daniel Vázquez wrote:
I've set my PGDATA variable in profile
export PGDATA=/home/mydata/pgsql/data
Testing variable for correct set in enviroment
$ echo $PGDATA
/home/mydata/pgsql/data
but when execute:
$ sudo /etc/init.d/postgresql-9.1 initdb
or execute:
$ sudo /etc/init.
On Thursday, February 09, 2012 10:25:51 PM Daniel Vázquez wrote:
> Hi!
>
> I've set my PGDATA variable in profile
> export PGDATA=/home/mydata/pgsql/data
>
> Testing variable for correct set in enviroment
> $ echo $PGDATA
> /home/mydata/pgsql/data
>
> but when execute:
> $ sudo /etc/init.d/postg
On 2/9/2012 3:25 PM, Daniel Vázquez wrote:
Hi!
I've set my PGDATA variable in profile
export PGDATA=/home/mydata/pgsql/data
Testing variable for correct set in enviroment
$ echo $PGDATA
/home/mydata/pgsql/data
but when execute:
$ sudo /etc/init.d/postgresql-9.1 initdb
or execute:
$ sudo /etc/
Hi!
I've set my PGDATA variable in profile
export PGDATA=/home/mydata/pgsql/data
Testing variable for correct set in enviroment
$ echo $PGDATA
/home/mydata/pgsql/data
but when execute:
$ sudo /etc/init.d/postgresql-9.1 initdb
or execute:
$ sudo /etc/init.d/postgresql-9.1 initdb -D /home/mydata/
On Thu, 9 Feb 2012, Andy Colson wrote:
If you create a serial column, dont put the column name or a value into your
insert statement.
create table junk (id serial, stuff text);
insert into junk(stuff) values ('my stuff');
Andy,
That's what I assumed would work but did not know for sure.
Chris,
pg_advisory_unlock (along with the other functions in that family) works
on a set of mythical objects with no actual meaning beyond what the
database administrator chooses to give them.
Thank you for your excellent description. I have never used the advisory
lock functionality that Pos
On Thu, Feb 9, 2012 at 9:49 AM, Rich Shepard wrote:
> I have a lot of data currently in .pdf files. I can extract the relevant
> data to plain text and format it to create a large text file of "INSERT INTO
> ..." rows. I need a unique ID for each row and there are no columns that
> would make a n
On 2/9/2012 10:49 AM, Rich Shepard wrote:
I have a lot of data currently in .pdf files. I can extract the relevant
data to plain text and format it to create a large text file of "INSERT
INTO
..." rows. I need a unique ID for each row and there are no columns that
would make a natural key so the
On Thu, 9 Feb 2012, Merlin Moncure wrote:
The record should be logically unique as well as physically unique (of if
it isn't, why bother making a unique constraint at all?). Sometimes you
*have* to force a surrogate, for example if certain (broken) client tools
need a primary key to work, but as
On Thu, Feb 9, 2012 at 10:49 AM, Rich Shepard wrote:
> I have a lot of data currently in .pdf files. I can extract the relevant
> data to plain text and format it to create a large text file of "INSERT INTO
> ..." rows. I need a unique ID for each row and there are no columns that
> would make a
I have a lot of data currently in .pdf files. I can extract the relevant
data to plain text and format it to create a large text file of "INSERT INTO
..." rows. I need a unique ID for each row and there are no columns that
would make a natural key so the serial data type would be appropriate.
On Fri, Feb 10, 2012 at 2:35 AM, Gary Chambers wrote:
> Is it possible that
> Postgres is not receiving a meaningful response with respect to
> ExclusiveLock locking (i.e. unable to really obtain an ExclusiveLock) due to
> VM "disk" residing on an NFS mount?
pg_advisory_unlock (along with the oth
Robins Tharakan writes:
> This is a case where I changed the name of a field in a table that a VIEW
> referred to, but the VIEW definition still points to the old name of the
> field. The surprise is that the VIEW still works (with live data).
Specifically, you mean that you had a column referenc
Chris (et al.),
Thanks for the reply. I have not replied sooner because I was hoping to get
some more feedback from the list.
I have a recently-migrated Pg cluster running 8.4.7 on Red Hat Enterprise
Linux Client release 5.7 (Tikanga) in a VMware VM that is logging the
subject warning. The ap
On Wed, Feb 8, 2012 at 15:37, 84.le0n <84.l...@gmail.com> wrote:
> This is an interesting solution, but I know a little bit PL/pgSQL and I
> don't know how provide SOUNDEX version in PL/pgSQL, I don't know SOUNDEX
> algo too.
> How can I provide soundex in PL/pgSQL ?
I wrote and posted a PL/pgSQL
On Πεμ 09 Φεβ 2012 02:32:37 Aleksey Tsalolikhin wrote:
> I got an alert from check_postgres.pl today on a long-running query on
> our production database, but our PostgreSQL 8.4.9 server log, which is
> configured to log queries over 5 seconds long
> ("log_min_duration_statement = 5000") does not s
Hi,
This is a case where I changed the name of a field in a table that a VIEW
referred to, but the VIEW definition still points to the old name of the
field. The surprise is that the VIEW still works (with live data).
Excerpt from psql (v9.1.2) given below.
The problem came up when I took a sche
I have a vacuum process that is sitting around and apparently not doing
anything. It's been around over 2000 seconds and is eating up no cpu.
It isn't waiting on a lock. Backtrace is this:
#0 0x00367aed4ff7 in semop () from /lib64/libc.so.6
#1 0x005d2a83 in PGSemaphoreLock (se
30 matches
Mail list logo
