Sorry if my question sounds stupid, but ...
Is there any way to get rid of postgres automatic generation of
system attribute column 'oid'? The problem is, that we've used for years
in our system tables attribute called oid (could be described as
varbit(16)), since there hasn't been any problems
Hi,
I have a problem:
I started out with a 6.3 version system, and attempted an upgrade to
Debian's unstable release (maybe version 7.?), which unfortunately
appeared to have failed the dump/import to the new database format.
Realizing this was probably not what I wanted in the first place I
Hey there,
(using postgres 6.5.0 - on Red Hat
Linux)
I have built a small application which has a table
for unique identifiers with a column of type int4.
This has one added to it each time a new key is
required. I am a little worried that at some point when the limit of int4
is reached
I am in the middle of a rather nasty experience that I hope someone
out
there can help solve.
My hard disk partition with the postgres data directory got full. I
tried to shut down postgres so I could clear some space, nothing
happened. So I did a reboot. On restart (after clearing some
I still haven't got rid of the problem with ISO 8859-2 charset and
Postgres. While I may use the database with correct Polish locale (by
using only --enable-locale) it is still impossible (in 7.1) to use unicode
encoding with Polish chars.
I have tried every possible combination of
I tried to search through mailing lists archives, but I didn't find any
thread about this issue. If you compile Perl to use shared library
libperl.so instead of static libperl.a, Perl documantation says that this
can decrease performances up to 15%. But, this is necessery to do to get
Postgres
Ryan Mahoney wrote:
Is it possible to select rows from a field based on the length of the data
in a varchar field?
length works fine in a select on a varchar field.
select a from b where length(a)=5;
You didn't ask for this, did you?
Grabbing different columns depending on values of
Greetings,
Trying to install PHP on a machine with the pgsql clients installed, e.g.:
./configure
gmake -C src/bin install
gmake -C src/interfaces install
gmake -C doc install
After ./configuring PHP --with-pgsql, I get errors regarding missing
headers, namely libpq/libpq-fs.h (Note:
Thanks. I told you it was stupid. But not as stupid as it sounds. I had tried
stty -a to find out what the erase character was (reported ^?), and had tried
typing that as my backspace, but it didn't work.
Oh well, stty erase ^H does work.
Thanks again,
Rob
"Brett W. McCoy" wrote:
On Tue,
Good day ppl,
I'm sorry if my question is a little bit stupid but, i have search already
an answer on Internet.
I have start postgres 7.1 with ssl suport with out any problems, i have
set on pg_hda.conf like this:
#localall trust
hostssl
Have you dropped and recreated the function since creating the trigger? Try
dropping and recreating the trigger. Errors like this happen because
database objects (tables, functions etc) are referenced by object ids (oids)
behind the scenes. Recreating an object (like a function) will give it a
Greeting!
it seems like locale support with glibc 2.2.2 is completely broken...
i got huge differences then performing tests in src/test/locale/koi8-r
i am running PG7.1 from cvs.
PS. locale itself isn't broken for sure
---(end of broadcast)---
Cefull Lo writes:
What is the upper limit of OID?
2^31-1
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
Matthew Hixson [EMAIL PROTECTED] writes:
Here's a problem I have with 7.1 final that I don't see with 7.1rc4. When
I do an initdb with 7.1 I get
syntax error 44 : -
7.1rc4 and 7.1 final are practically indistinguishable. I think you
messed up and initdb'd with something else.
The
Toomas Gavrilin writes:
Is there any way to get rid of postgres automatic generation of
system attribute column 'oid'?
No.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 1: subscribe
With 7.0.3, the file "postmaster.opts" listed the options
with which the postmaster had been started.
However, with 7.1 and the new "postgresql.conf" file, any
options set via that file are not listed in "postmaster.opts".
I like the warm, cozy feeling from knowing that the
options set in
On Thu, 19 Apr 2001, Toomas Gavrilin wrote:
Sorry if my question sounds stupid, but ...
Is there any way to get rid of postgres automatic generation of
system attribute column 'oid'? The problem is, that we've used for years
in our system tables attribute called oid (could be described as
I just upgraded from 7.0.3 to 7.1 (using the RH rpms) with no
major problems. Nice!
However, I'm getting some strange behaviour from the init
script (/etc/rc.d/init.d/postgresql). In particular, a
restart when the database is running fails because the
"sleep 2" in stop() is no longer long
Diana Cionoiu writes:
#localall trust
hostssl all 127.0.0.1 255.255.255.255 trust
#host all 127.0.0.1 255.255.255.255 trust
and i have try
psql -h 127.0.0.1 teste
what is working if i set
Have you modified the function since making the trigger?
If you drop/create the function to make any changes you need to
drop/create objects that depend on that function (views, triggers, etc)
On Wed, 18 Apr 2001, Keith Menard wrote:
All,
I am new to pgSQL so here goes. I am
I had the same problems my self w/ php and pam_pgsql
looks like 7.1 doesn't put things into the folders that you are expecting.
ie 7.0.3 places libs in /usr/lib/pgsql, in 7.1 they go in /usr/lib/postgres
Mike
Greetings,
Trying to install PHP on a machine with the pgsql clients installed,
Steve Wampler writes:
With 7.0.3, the file "postmaster.opts" listed the options
with which the postmaster had been started.
However, with 7.1 and the new "postgresql.conf" file, any
options set via that file are not listed in "postmaster.opts".
I like the warm, cozy feeling from knowing
Pimenov Yuri wrote:
Greeting!
it seems like locale support with glibc 2.2.2 is completely broken...
i got huge differences then performing tests in src/test/locale/koi8-r
i am running PG7.1 from cvs.
PS. locale itself isn't broken for sure
Locale collation and other issues were
Steve Wampler [EMAIL PROTECTED] writes:
Well, it looks like I got bit by this after all. Can someone show
me a rule to attach to a view ("attributes") to invoke a trigger function
(insert_or_update)?
The trigger function maps the update into either an insert or an update
on the underlying
Pruner Jan writes:
Some of these values are for insert, some for update = I cannot use COPY.
How can I get confirmation, that insert/update was successful?
Is there something like @@error in postgresql?
Each client interface has its own way of reporting errors. See the
documentation of the
Tom Lane wrote:
Steve Wampler [EMAIL PROTECTED] writes:
One of the listed bug fixes is:
Disallow INSERT/UPDATE/DELETE on views
Can some one give me a little insight on what this
implies?
It means that if you try to do INSERT/UPDATE/DELETE on a view that
doesn't have a rule to
Adam Rossi wrote:
I just wanted to pass this along to everyone checking out the new 7.1
release. The jdbc jars that are included with the current RPM's are from the
7.0.3 release. So if you try to take advantage of the new unlimited size text
As soon as I can get either pre-built 7.1 JDBC
Tom Lane wrote:
Steve Wampler [EMAIL PROTECTED] writes:
Well, it looks like I got bit by this after all. Can someone show
me a rule to attach to a view ("attributes") to invoke a trigger function
(insert_or_update)?
The trigger function maps the update into either an insert or an
Lamar Owen [EMAIL PROTECTED] writes:
Pimenov Yuri wrote:
Greeting!
it seems like locale support with glibc 2.2.2 is completely broken...
i got huge differences then performing tests in src/test/locale/koi8-r
i am running PG7.1 from cvs.
PS. locale itself isn't broken for sure
Trond Eivind Glomsrd wrote:
it seems like locale support with glibc 2.2.2 is completely broken...
What exactly is claimed to be broken? If this is the case sensitivity
issue, that would count as a postgresql bug.
Whatever the sentence above your question means. We'll have to wait on
the
Lamar Owen [EMAIL PROTECTED] writes:
Adam Rossi wrote:
I just wanted to pass this along to everyone checking out the new 7.1
release. The jdbc jars that are included with the current RPM's are from the
7.0.3 release. So if you try to take advantage of the new unlimited size text
As
Lamar Owen [EMAIL PROTECTED] writes:
Trond Eivind Glomsrd wrote:
Which case-sensitivity issue? The one about table and column names? Or
a different one? (sitting confused in Pisgah Forest)
I remember there were some issues about someone claiming glibc was broken
(with LANG set to
Trond Eivind Glomsrd wrote:
Which case-sensitivity issue? The one about table and column names? Or
a different one? (sitting confused in Pisgah Forest)
I remember there were some issues about someone claiming glibc was broken
(with LANG set to anything but C/POSIX, because it will sort
33 matches
Mail list logo
