"Kelvin T. Leung" <[EMAIL PROTECTED]> writes:
> Now, I am unable to run psql using my own OS login a/c. And I get an
> error message:
> psql: error while loading shared libraries: psql: undefined symbol:
> get_progname
This is a version-skew issue: you are trying to use a psql executable
w
Richard Huxton wrote:
Rob Brenart wrote:
I'm running postgresql 8.0 under WindowsXP for a development box (the
production server isn't up yet, and will be linux, so I don't know
that the problem will travel)...
Using a PHP connection to it for a simple web app, if I leave the app
alone for
Hi,
I am new to postgres. I hope that ppl out there can give me some help.
I have installed postgres on my system, which runs with Fedora 2 on a
P-IV machine.
I have created a postgres account. I am able to use psql (under
postgres a/c) without any problem.
I have created another postgres
On 19.07.2005 20:56, Craig Bryden wrote:
What is the syntax if I want to use the exception clause in a pl/pgsql
function, but am not looking for a particular error. Kind of like a "any
error" type thing.
35.7.5. Trapping Errors
http://www.postgresql.org/docs/8.0/interactive/plpgsql-control-str
Hi All
What is the syntax if I want to use the exception clause in a pl/pgsql
function, but am not looking for a particular error. Kind of like a "any
error" type thing.
some thing like:
CREATE OR REPLACE FUNCTION func1(p_Param1 int4)
RETURNS int4
AS
$$
DECLARE
v_Var1 int4;
BEGIN
[Sta
FYI, this is deprecated in favor of a .pgpass file.
See:
http://www.postgresql.org/docs/8.0/static/libpq-pgpass.html
On Tue, 2005-07-19 at 13:01, Oisin Glynn wrote:
> BAT FILE SHOULD CONTAIN
>
> set PGPASSWORD=postgres
> "psql.exe" MYDATABASE -U postgres -f mysqlfile.sql
>
>
> Oisin
> - O
[sorry for resending again. i am not at my usual desktop at the moment and
used the wrong sender address]
Am Dienstag, 19. Juli 2005 15:40 schrieb Tom Lane:
> Janning Vygen <[EMAIL PROTECTED]> writes:
> > On more related question:
> > I updated pg_trigger and pg_constraint and changed all my FK:
On Tue, Jul 19, 2005 at 11:48:16AM +0200, Martijn van Oosterhout wrote:
> int, bool, bool 6 bytes, no padding
> bool, int, bool 9 bytes, including 3 bytes padding
> bool, bool, int 8 bytes, including 2 bytes padding
We store bool's in a byte and don't compact? That would be another very
Josef Springer <[EMAIL PROTECTED]> writes:
> i want to use psql using the --username option. But i do not find an
> option to pass the password.
There are very good reasons for that.
> I want to use psql in a batch, so i want to automate it.
Consider using a ~/.pgpass file.
BAT FILE SHOULD CONTAIN
set PGPASSWORD=postgres
"psql.exe" MYDATABASE -U postgres -f mysqlfile.sql
Oisin
- Original Message -
From: "Josef Springer" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, July 19, 2005 1:26 PM
Subject: [GENERAL] How to pass the password for login in psql
Hi,
i wa
Thanks Tom,
we now stay with 32bit to allow backward compatibilty with XEON which
is needed as a fail-over system.
The question is which gcc cflags are best used with XEON and Opteron to
achieve fail-over compatibility. This is what we used for postgresql
8.0.3:
XEON, RHEL 3.0 AS:
CFLAG
Hi,
i want to use psql using the --username option. But i do not find an
option to pass the password. I want to use psql in a batch, so i want to
automate it.
Best Regards,
Josef Springer
---(end of broadcast)---
TIP 3: Have you checked our ext
>Richard Huxton writes:
>> [* Actually, I think NULLs are typed in SQL, which means you should be
>> able to get type violations. ]
>
>I'm pretty sure the entire construct is illegal per a strict reading of
>the SQL spec --- the spec only allows NULL to appear in contexts where a
>datatype can be
Hi,
I am trying RAMFS solution with Postgres wherein I am pushing the most
heavily used tables in RAM.
I have 32GB RAM on a 64 bit opteron machine. My database size is 40GB. I
think Linux allows max. of 16GB (half of available RAM) to be used directly
to push tables to it.
I am concerned ab
What happened was that I realized that here it was already noon on
Tuesday, and I hadn't made a fool of myself in public yet this week
I blindly took the output from somebody else's query and didn't look at
the pg_locks table myself. Once I was able to look at it with a live
test running, ever
Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Tue, 2005-07-19 at 10:25, Tom Lane wrote:
>> None of the index types support entries larger than BLOCKSIZE-less-a-bit,
>> so switching to a different index type won't do more than push the
>> problem out by a factor of about 3.
> Are they compressed?
On Tue, 2005-07-19 at 10:25, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > On Tue, 2005-07-19 at 05:42, Dennis Bjorklund wrote:
> >> You can index text fields, but you can't insert values bigger then
> >> BLOCKSIZE/3 when you have an index on that column.]
>
> > Please note that
Tom Lane a écrit :
Samuel Thoraval <[EMAIL PROTECTED]> writes:
I have been trying this example not executing the GRANT UPDATE statement
at first to check that user b doesn't have the right to update. The
problem is that even though B was not granted the update privilege, it
w
Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Tue, 2005-07-19 at 05:42, Dennis Bjorklund wrote:
>> You can index text fields, but you can't insert values bigger then
>> BLOCKSIZE/3 when you have an index on that column.]
> Please note that the size limitation is for btree indexes, the most
> com
Samuel Thoraval <[EMAIL PROTECTED]> writes:
> I have been trying this example not executing the GRANT UPDATE statement
> at first to check that user b doesn't have the right to update. The
> problem is that even though B was not granted the update privilege, it
> worked anyway. In other words, s
Richard Huxton writes:
> [* Actually, I think NULLs are typed in SQL, which means you should be
> able to get type violations. ]
I'm pretty sure the entire construct is illegal per a strict reading of
the SQL spec --- the spec only allows NULL to appear in contexts where a
datatype can be assign
Hello!
>>> Well, it would obviously be better if PG could figure out it was safe,
>>> but I'm not sure there's a general case where it is. You can see it's OK
>>> because you know there's only one row in your SELECT result-set.
>
>> I think, it's OK because NULL can be compared with anything
>
On Tue, 2005-07-19 at 05:42, Dennis Bjorklund wrote:
> On Mon, 18 Jul 2005, Jaime Casanova wrote:
>
> > I don't think you could create indexes on text fields... there are
> > other type of indexes for that... tsearch2 for example
>
> You can index text fields, but you can't insert values bigger t
"David Parker" <[EMAIL PROTECTED]> writes:
> The observed behavior was that a pg_dump running with nothing else going
> on takes a couple of minutes, but when we are running some system tests
> that do heavy updates to a selection of application tables, it appears
> that pg_dump blocks until the up
I have been trying to use views to restrict access to a subset of data
as stated :
Using Andrus's example for user B with document in public schema :
REVOKE ALL FROM public.document;
CREATE SCHEMA b AUTHORIZATION b;
CREATE VIEW b.document AS SELECT * FROM public.document WHERE
DocumentType
On Mon, 18 Jul 2005, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Mon, 18 Jul 2005, Tom Lane wrote:
> >> I don't see why.
>
> > Except that before I think the order would have looked like (for 1 row)
> > Originating Action
> > Trigger A on originating table that does update
>
Am Montag, 18. Juli 2005 18:18 schrieb Tom Lane:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Mon, 18 Jul 2005, Tom Lane wrote:
> >> I don't see why.
> >
> > Except that before I think the order would have looked like (for 1 row)
> > Originating Action
> > Trigger A on originating table that
Ilja Golshtein wrote:
Well, it would obviously be better if PG could figure out it was safe,
but I'm not sure there's a general case where it is. You can see it's OK
because you know there's only one row in your SELECT result-set.
I think, it's OK because NULL can be compared with anything
"Ilja Golshtein" <[EMAIL PROTECTED]> writes:
>> Well, it would obviously be better if PG could figure out it was safe,
>> but I'm not sure there's a general case where it is. You can see it's OK
>> because you know there's only one row in your SELECT result-set.
> I think, it's OK because NULL
What is everyone's opinion for exclusively using Stored Procedures
for increased security? The scenario I am thinking of means having
one user which is widely accessible (large numbers of staff/user for
example) and only has access to some stored procedures, which where
create with SECURITY
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
> when have a 8.0.3 database running on a XEON machine. We want to replace
> it with an Opteron where postgresql is to be compiled with 64bit. Do we
> need a dump/restore or can we just start the db with the new compilation?
I'd bet y
We have an issue
with running pg_dump while a database is under reasonably heavy update load.
This is 7.4.5 on Solaris 9/intel.
The observed
behavior was that a pg_dump running with nothing else going on takes a couple of
minutes, but when we are running some system tests that do heavy upd
Janning Vygen <[EMAIL PROTECTED]> writes:
> On more related question:
> I updated pg_trigger and pg_constraint and changed all my FK:
> UPDATE pg_trigger
> SET
> tgdeferrable = true,
> tginitdeferred = true
> WHERE tgconstrname LIKE 'fk_%'
> ;
> UPDATE pg_constraint
> SET
> condeferrable
Rob Brenart wrote:
I'm running postgresql 8.0 under WindowsXP for a development box (the
production server isn't up yet, and will be linux, so I don't know that
the problem will travel)...
Using a PHP connection to it for a simple web app, if I leave the app
alone for a bit (about 20 seconds
>Well, it would obviously be better if PG could figure out it was safe,
>but I'm not sure there's a general case where it is. You can see it's OK
>because you know there's only one row in your SELECT result-set.
I think, it's OK because NULL can be compared with anything
with predictable resul
Ilja Golshtein wrote:
When I invoke
select 1 where 5 in (null)
everything is Ok,
though when I try
select 1 where 5 in (select null)
I get
ERROR: failed to find conversion function from "unknown" to integer.
Is it desired behavior or subject to change
in future versions of PG?
Well,
On Mon, 18 Jul 2005, Jaime Casanova wrote:
> I don't think you could create indexes on text fields... there are
> other type of indexes for that... tsearch2 for example
You can index text fields, but you can't insert values bigger then
BLOCKSIZE/3 when you have an index on that column.
--
/Den
Hi!
I've already asked this question a month ago -
it remains unanswered.
Dare to repeat since this issue is rather important for me.
So.
When I invoke
select 1 where 5 in (null)
everything is Ok,
though when I try
select 1 where 5 in (select null)
I get
ERROR: failed to find conversion f
On Tue, Jul 19, 2005 at 02:02:28AM +0200, Dawid Kuroczko wrote:
> Out of curiosity, do I understand right that if I create table
>
> CREATE TABLE sample1 (
> a boolean,
> b int,
> c boolean
> );
>
> ...it will take more storage than:
>
> CREATE TABLE sample2 (
> b int,
> a bo
I'm running postgresql 8.0 under WindowsXP for a development box (the
production server isn't up yet, and will be linux, so I don't know that
the problem will travel)...
Using a PHP connection to it for a simple web app, if I leave the app
alone for a bit (about 20 seconds I'd say) and do some
Hi,
when have a 8.0.3 database running on a XEON machine. We want to replace
it with an Opteron where postgresql is to be compiled with 64bit. Do we
need a dump/restore or can we just start the db with the new compilation?
Regards,
Dirk
---(end of broadcast)
resending it because i used the wrong mail address. sorry!
Am Montag, 18. Juli 2005 18:18 schrieb Tom Lane:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Mon, 18 Jul 2005, Tom Lane wrote:
> >> I don't see why.
> >
> > Except that before I think the order would have looked like (for 1 row)
> >
On Tue, Jul 19, 2005 at 02:02:28AM +0200, Dawid Kuroczko wrote:
> On 7/18/05, Lincoln Yeoh wrote:
> > However, maybe padding for alignment is a waste on the disk - disks being
> > so much slower than CPUs (not sure about that once the data is in memory ).
> > Maybe there should be an option to reo
Hi list,
I am working with postgres 8.0.3 on a HP Pro Liant Xeon box under SuSE
Linux 9.1
When dumping a database, I got the error
pg_dump: SQL command to dump the contents of table "bearbeitungsschritt"
failed: PQendcopy() failed.
pg_dump: Error message from server: ERROR: missing chunk nu
44 matches
Mail list logo
