Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> Bas Scheffers writes:
> >>> When opening a file in psql, ~ (the user's home dir) is resolved when
> >>> using tab completion to find the file, but when you hit enter and psql
> >>> actualy tries to open it,
This now works in current CVS and will be in 7.4 final:
test=> select * from pg_l
pg_language pg_largeobject pg_listener pg_locks
---
Gaetano Mendola wrote:
> Hi all
> I'm esperiencing probl
Joe Conway <[EMAIL PROTECTED]> writes:
> I agree, and this brings up a question that I've pondered before. Why do
> we ever *require* and initdb when only metadata has changed (i.e. the
> contents of the system catalogs, not catalog or page structure)?
In some cases we have to do it because ther
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I think we should fix it but not force an initdb ---
information_schema is new and I am not sure how many people are using
it.
Yeah, I'm leaning that way too. We could publicize a script to fix the
problem in any beta5 or RC1 databases tha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think we should fix it but not force an initdb ---
> information_schema is new and I am not sure how many people are using
> it.
Yeah, I'm leaning that way too. We could publicize a script to fix the
problem in any beta5 or RC1 databases that people d
Marc G. Fournier wrote:
>
>
> On Sat, 8 Nov 2003, Tom Lane wrote:
>
> > <[EMAIL PROTECTED]> writes:
> > >select * from information_schema.tables;
> > >ERROR: unrecognized privilege type: "RERERENCES"
> >
> > > Replacing the word "RERERENCES" with "REFERENCES" in
> > > the predicate "has
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sat, 8 Nov 2003, Tom Lane wrote:
>> I've applied the patch but am loathe to force an initdb this late in
>> the beta cycle. Any opinions out there?
> Annoying as a spelling mistake is (and, from my read of the above, that is
> all it is?), I don
On Sat, 8 Nov 2003, Tom Lane wrote:
> <[EMAIL PROTECTED]> writes:
> >select * from information_schema.tables;
> >ERROR: unrecognized privilege type: "RERERENCES"
>
> > Replacing the word "RERERENCES" with "REFERENCES" in
> > the predicate "has_table_privilege(c.oid,
> > 'RERERENCES'::te
Josh Berkus <[EMAIL PROTECTED]> writes:
> Here's a non-showstopper in 7.4RC1, but probably good to fix before RC2:
> 1) Create a file with *only* a block comment in it, or with a block comment as
> the very last line.
> 2) run psql -f filename database
> You will get some odd feedback on STDERR:
Tom Lane wrote:
> <[EMAIL PROTECTED]> writes:
> >select * from information_schema.tables;
> >ERROR: unrecognized privilege type: "RERERENCES"
>
> > Replacing the word "RERERENCES" with "REFERENCES" in
> > the predicate "has_table_privilege(c.oid,
> > 'RERERENCES'::text)" near the end of t
Oliver Siegmar wrote:
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
>
> Your name : Oliver Siegmar
> Your email
Micah Yoder <[EMAIL PROTECTED]> writes:
> ... I am wondering if you all think this sounds like a hardware
> problem.
Yeah, it does. Have you tried running memtest86?
It could also be a kernel problem --- I'm not sure 2.4.16 had all the
SMP bugs flushed out of it. Consider getting a later kerne
Paul Tillotson <[EMAIL PROTECTED]> writes:
> pg_dumpall does not save all access control permissions on a database.
> (This is true for at least the CREATE permission.)
This is fixed as of 7.4.
regards, tom lane
---(end of broadcast)---
<[EMAIL PROTECTED]> writes:
>select * from information_schema.tables;
>ERROR: unrecognized privilege type: "RERERENCES"
> Replacing the word "RERERENCES" with "REFERENCES" in
> the predicate "has_table_privilege(c.oid,
> 'RERERENCES'::text)" near the end of the view SQL
> seems to correct
Robert Grabowski <[EMAIL PROTECTED]> writes:
> Some times set user's search_path before schema creation is
> necessary. I suggest to change error at alter user to notice.
I can't imagine why you think that's necessary.
regards, tom lane
---(end
This is fixed in 7.4.X and in fact 7.4 pg_dumpall will work on a 7.3.X
database.
---
Paul Tillotson wrote:
>
> POSTGRESQL
POSTGRESQL BUG REPORT TEMPLATE
Your name : Paul Tillotson
Your email address : ptchristendom at yaho
After recompiling with GCC 3.1 it fails when I'm running initdb to
create the cluster -- it's a shmget error again. I believe that takes
both Tcl and PostgreSQL out of the suspect pool and leaves Mac OS 10.3
as the primary culprit. I installed Panther last week from scratch
(reformatted disk et
Just compiled PG 7.3.4 with GCC 3.1 on Panther and it exhibits the same
problem, but generates a SIGSEGV instead of a SIGBUS. Here's the log:
LOG: server process (pid 12078) was terminated by signal 11
LOG: terminating any other active server processes
LOG: all server processes terminated; rei
Hi Tom,
On Nov 4, 2003, at 4:48 PM, Tom Lane wrote:
Here's the code that triggers it:
create function pltcl_call_handler() RETURNS LANGUAGE_HANDLER
as 'pltcl.so' language 'c';
I don't think so. That's a startup failure; it can not be triggered by
executing a SQL command, because if the postm
Hi.
I can't set user's search_path to no exists schema by simple alter
user set ... . I get this message:
test=# CREATE USER test;
CREATE USER
test=# ALTER USER test SET search_path TO noexists;
ERROR: schema "noexists" does not exist
But this is possible by simple trick:
test=# CREATE SCHE
To produce the error, the following query was issued:
select * from information_schema.tables;
Generates the following error message:
ERROR: unrecognized privilege type: "RERERENCES"
Replacing the word "RERERENCES" with "REFERENCES" in
the predicate "has_table_privilege(c.oid,
'RERERENC
POSTGRESQL BUG REPORT TEMPLATE
Your name : Thomas Erskine
Your email address : [EMAIL PROT
POSTGRESQL BUG REPORT TEMPLATE
Your name : Oliver Siegmar
Your email address : [EMAIL PROTECTED]
P
It turns out that the "createlang pltcl" failure on OS X 10.3 was due to
our ps_status code doing the wrong thing. I have committed a fix.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once w
Hello
I dont know is this a bug but when I use COPY to load data
into table sequence of the primary key in this table have
always start value = 1. But in the table is about 13000
rows :-). I wrote script like this to coorect this
sequence
select
setval('public.kom_kontrahenciref_idkre_seq',(
platform: PostgreSQL 7.3.4, RedHat 7.3, linux 2.4.18
I've recently tried to restore my database and get this:
pg_restore: [archiver (db)] could not execute query: ERROR: Function pftype_id_lookup(text) does not exist
Unable to identify a function that satisfies the given argument types
Tom sent a mail indicating it was fixed. Thanks,
Palle
--On fredag, november 07, 2003 09.32.54 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
I don't remember what we did with -lbind, but if someone shows up with
BeOS, we will get it working.
Title: Message
I
originally posted this in the novice section. I'm not really sure
where it belongs. Thanks for your help.
Louise
-Original Message-From: Louise Cofield
[mailto:[EMAIL PROTECTED] Sent: Friday, November 07, 2003 2:15
PMTo: '[EMAIL PROTECTED]'Subject: Createdb
Pr
Was this problem fixed? Can I request the problem report @ FreeBSD to be
closed?
Thanks,
Palle
--On torsdag, juni 12, 2003 18.51.18 -0400 "Yves R. Crevecoeur"
<[EMAIL PROTECTED]> wrote:
Don't break BeOS support.
A new version of BeOS will be released very soon.
http://www.yellowtab.com
http://w
POSTGRESQL BUG REPORT TEMPLATE
Your name : Jan Poslusny
Your email address : [EMAIL PROTECTED]
Syst
POSTGRESQL BUG REPORT TEMPLATE
Your name : Micah Yoder
Your email address : [EMAIL PROTECTED]
POSTGRESQL BUG REPORT TEMPLATE
Your name : Eric Jain
Your email address : [EMAIL PROTECTED]
System Configuration
-
Hello
I dont know is this a bug but when I use COPY to
load data into table sequence of the primary key in this table have always start
value = 1. But in the table is about 13000 rows :-). I wrote script like this to
coorect this sequence
select
setval('public.kom_kontrahenciref_idkre_seq'
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Reece Hart <[EMAIL PROTECTED]> writes:
> > I have a hunch about why this happens and is rare. The pftype_id_lookup
> > function was created AFTER some of the tables using 'alter table set
> > default ...'. Thus, the function's OID is greater than the OID of t
35 matches
Mail list logo
