Hi Bruce,
you might add that I did the following useful enhancement to ECPG:
- EXECUTE ... INTO ...implemented
- multiple row descriptor support (e.g. CARDINALITY)
I don't feel that my humble contribution of a few lines is important but
the improvement made really is important (n times
Shouldn't this work?
create table test ( a int, unique (oid) );
ERROR: CREATE TABLE: column oid named in key does not exist
Because this works:
create table test ( a int );
CREATE
alter table test add unique (oid);
NOTICE: ALTER TABLE/UNIQUE will create implicit index 'test_oid_key' for
Johann Zuschlag [EMAIL PROTECTED] writes:
create function numeric_neq(numeric,float8) returns bool as '
select $1 = $2::numeric;
' language 'sql';
create operator (
leftarg=numeric,
rightarg=float8,
procedure=numeric_neq,
commutator='',
negator='',
^^
Johann Zuschlag [EMAIL PROTECTED] writes:
select * from pg_operator where oid = 280343;
select * from pg_operator where oid = 280344;
Attached you find the results of the above selects.
Okay ... are there any rows in pg_operator with OID 280346 or 280347 ?
regards,
Johann Zuschlag [EMAIL PROTECTED] writes:
Okay ... are there any rows in pg_operator with OID 280346 or 280347 ?
Yes, seems so. See the attachment. Again, the negator stuff
never worked for numeric.
Looks like these are shell operator definitions left over from
commutator or negator forward
Postgresql 7.1.3
I'm having a problem with createlang.
Commands:
[postgres@boxy postgres]$ createdb test1
Password: - Correct
password
CREATE DATABASE
[postgres@boxy postgres]$ createlang plpgsql test1
Password:
- Original Message -
From: Bill Studenmund [EMAIL PROTECTED]
Sent: Friday, October 19, 2001 2:04 PM
It means that when you want to use one of the built in functions
(date_part, abs, floor, sqrt etc.) you don't have to prefix it with
standard.. You can just say date_part(),
On Sun, 21 Oct 2001, Serguei Mokhov wrote:
- Original Message -
From: Bill Studenmund [EMAIL PROTECTED]
Sent: Friday, October 19, 2001 2:04 PM
Quick question: would it be possible then create a 'system' package
and 'system' (or 'master' if you will) schema (when it's
Thomas Lockhart [EMAIL PROTECTED] writes:
I'm with Peter on this one. I'd like to *not* clutter up the code and
error reporting with hints and suggestions which may or may not be to
the point.
We *should* have docs which list error messages and possible solutions,
and throwing that
I just tried it with current sources and got:
#$ aspg createlang plpgsql test
Password: - bad password
FATAL 1: Password authentication failed for user postgres
psql: FATAL 1: Password authentication failed for user postgres
createlang: external
On Sun, 21 Oct 2001 12:42:57 -0400, Tom Lane wrote:
select * from pg_operator where oid = 280343;
select * from pg_operator where oid = 280344;
Attached you find the results of the above selects.
Okay ... are there any rows in pg_operator with OID 280346 or 280347 ?
Yes, seems so. See the
On Sat, 20 Oct 2001 12:36:16 -0400, Tom Lane wrote:
That's what you showed us already. What I'd like to see is the
original database contents, particularly
select * from pg_operator where oid = 280343;
select * from pg_operator where oid = 280344;
so we can see why pg_dump is
speedboy [EMAIL PROTECTED] writes:
Ok, so it connects four times. From a users perspective that might be
confusing. Is it possible to only prompt once for the password,
This would require replacing the createlang shell script with a
specialized C program. (Or, perhaps, adding
Good day,
My name is John Worsley, I'm one of the authors of the new O'Reilly
PostgrSQL book. We're wrapping up the PL/pgSQL chapter's technical edit
right now, but there are a couple of concerns that I was hoping someone
might be able to help with.
Mainly, the existing documentation on the
Not possible to accept both forms at present and issue a notice that
LIMIT m,n is deprecated?
If LIMIT m,n is found, internally re-write it to LIMIT m OFFSET n and
press on.
This should appease everyone and still allow the 'proper' form to be
implemented right now. There isn't just the
On Sat, 20 Oct 2001, Joel Burton wrote:
On Sat, 20 Oct 2001, Aasmund Midttun Godal wrote:
Can a rule see the where statement in a query which it has been
triggered by? or is it simply ignored?? what happens?
Looking over your question, I wanted to clarify the problem a bit, so:
I just tried it with current sources and got:
#$ aspg createlang plpgsql test
Password: - bad password
FATAL 1: Password authentication failed for user postgres
psql: FATAL 1: Password authentication failed for user postgres
createlang: external
Thomas Lockhart [EMAIL PROTECTED] writes:
A bit more information: an unadorned -i fails:
I believe this is fixed now.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
Thomas Lockhart [EMAIL PROTECTED] writes:
I think Hiroshi's point is the same as mine: discussions of feature
changes need to happen on -hackers before being implemented.
Well, IIRC there *was* some discussion about this some months back, and
no one particularly objected to changing it to be
Hello PostgreSQl Users!
PostSQL V 7.1.1:
I have defined a table and the necessary indices.
But the index is not used in every SELECT. (Therefore, the selects are
*very* slow, due to seq scan on
20 million entries, which is a test setup up to now)
The definitions can be seen in the annex.
Does
Bruce Momjian wrote:
[snip]
What do others think?
Please reverse your change and go into beta quickly.
I need more information. What do you want reversed, and are there
enough votes to reverse those votes already made?
--
Bruce Momjian|
On Sun, 21 Oct 2001, Peter Eisentraut wrote:
Bill Studenmund writes:
The big one for now is how should you log into one schema or another?
psql database.schema ?
Each user has a default schema, which is by default the schema with the
same name as the user name, or if no such schema
(switched thread to hackers)
... If the 'tip' is localized to a few lines, usually in
gram.y, I don't see a reason not to help people find the right answer.
It helps them and reduces redundant bug repots. I can't imagine a
reason not to do it unless it starts to make our code more complex.
Shouldn't there be some form of CREATE TABLE AS / WITHOUT OIDS?
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
Bruce Momjian wrote:
(switched thread to hackers)
... If the 'tip' is localized to a few lines, usually in
gram.y, I don't see a reason not to help people find the right answer.
It helps them and reduces redundant bug repots. I can't imagine a
reason not to do it unless it
Added. I will update the HISTORY file today or tomorrow to add newer
changes than 2001-09-13.
---
Hi Bruce,
you might add that I did the following useful enhancement to ECPG:
- EXECUTE ... INTO ...implemented
Bill Studenmund writes:
The big one for now is how should you log into one schema or another?
psql database.schema ?
Each user has a default schema, which is by default the schema with the
same name as the user name, or if no such schema exists, it's the DEFAULT
schema (which I believe is
Joel Burton [EMAIL PROTECTED] writes:
CREATE VIEW dbl AS SELECT id * 2 as id, name FROM raw;
CREATE RULE dbl_update AS ON UPDATE TO dbl DO INSTEAD UPDATE raw SET
id = NEW.id, name = NEW.name WHERE OLD.id = id;
Surely you'd need something like
CREATE RULE dbl_update AS ON UPDATE TO dbl DO
Don't think so. I think the rule doesn't make any sense.
NEW.id and OLD.id are probably dbl values, so saying OLD.id=id (where id
is raw.id since that's the update table) isn't correct. It probably
should be OLD.id=id*2 (which seems to work for me, btw) It's editing
a different row than
I am confused. While LIMIT and OFFSET may are potential SQL standard
reserved words, I don't see how LIMIT #,# would ever be a standard
specification. Do you see this somewhere I am missing. Again, LIMIT
#,# is the only syntax we are removing.
If you are confident that LIMIT #,#
On Sat, 20 Oct 2001, Rod Taylor wrote:
But what if you want a C function to set a variable which can be
accessed using an SQL, perl, PLpgSQL or other function type?
Shouldn't a global variable be global between all types of functions?
No. Doing that requires that all languages have the same
I just checked:
ftp://ftp.us.postgresql.org/dev/postgresql-base-snapshot.tar.gz
and the snapshot has the proper file contents, showing doc/TODO with a
date of October 19th.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610)
Hi Steve,
Your question about - pg_proc
select t.typname from pg_type t , pg_proc p
where p.proname = 'your_stored_procedure' and p.proargtypes[0] = t.oid ;
select t.typname from pg_type t , pg_proc p
where p.proname = 'your_stored_procedure' and p.proargtypes[1] = t.oid ;
...
select
Bruce Momjian wrote:
[snip]
What do others think?
Please reverse your change and go into beta quickly.
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
I am confused. While LIMIT and OFFSET may are potential SQL standard
reserved words, I don't see how LIMIT #,# would ever be a standard
specification. Do you see this somewhere I am missing. Again, LIMIT
#,# is the only syntax we are removing.
If you are confident that LIMIT
Bruce Momjian wrote:
I don't think that enough votes are needed to reverse
the change. You broke the discussion first rule.
Are you subscribed to general? We had a big discussion there and there
I know the discussion and I've thought Peter's objection was
suffienctly valid to reverse
So the result of all this is that the behaviour of my ADD UNIQUE code is
correct in this case?
Peter Eisentraut [EMAIL PROTECTED] writes:
Shouldn't this work?
create table test ( a int, unique (oid) );
ERROR: CREATE TABLE: column oid named in key does not exist
Now it does.
In 7.2 you
Hello PostgreSQl Users!
PostSQL V 7.1.1:
You should upgrade to 7.1.3 at some point...
I have defined a table and the necessary indices.
But the index is not used in every SELECT. (Therefore, the selects are
*very* slow, due to seq scan on
20 million entries, which is a test setup up to
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
So the result of all this is that the behaviour of my ADD UNIQUE code is
correct in this case?
The AlterTable code wasn't broken; the error was in parser/analyze.c,
which was prematurely rejecting the command.
Peter Eisentraut [EMAIL
[ BCC to general ]
Added to TODO:
* Remove LIMIT #,# and force use LIMIT and OFFSET clauses in 7.3 (Bruce)
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+
On Monday 22 October 2001 10:32 pm, Tom Lane wrote:
Thomas Lockhart [EMAIL PROTECTED] writes:
I think Hiroshi's point is the same as mine: discussions of feature
changes need to happen on -hackers before being implemented.
[snip]
Subscriptions to other mailing lists should not be required
Thomas Lockhart [EMAIL PROTECTED] writes:
I think Hiroshi's point is the same as mine: discussions of feature
changes need to happen on -hackers before being implemented.
Well, IIRC there *was* some discussion about this some months back, and
no one particularly objected to changing it
Reiner Dassing [EMAIL PROTECTED] writes:
Hello PostgreSQl Users!
PostSQL V 7.1.1:
I have defined a table and the necessary indices.
But the index is not used in every SELECT. (Therefore, the selects are
*very* slow, due to seq scan on
20 million entries, which is a test setup up to
But that's past. It's mighty close to beta -- is this fix a showstopper?
The behavior currently is rather broken according to the results of the
discussion on general. Do we really want a whole 'nother major version cycle
to pass before this kludge is fixed? Six months to a year down
Thomas Lockhart [EMAIL PROTECTED] writes:
I'm with Peter on this one. I'd like to *not* clutter up the code and
error reporting with hints and suggestions which may or may not be to
the point.
We *should* have docs which list error messages and possible solutions,
and throwing that info into
A bit more information: an unadorned -i fails:
I believe this is fixed now.
Seems to be, on my Linux box. Thanks for tracking it down...
- Thomas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
I need more information. What do you want reversed,
revision 2.253
date: 2001/09/23 03:39:01; author: momjian; state: Exp; lines: +3 -3
Implement TODO item:
* Change LIMIT val,val to offset,limit to match MySQL
and the related description in
I just tried it with current sources and got:
#$ aspg createlang plpgsql test
Password: - bad password
FATAL 1: Password authentication failed for user postgres
psql: FATAL 1: Password authentication failed for user postgres
createlang: external error
Bruce Momjian wrote:
Bruce Momjian wrote:
[snip]
What do others think?
Please reverse your change and go into beta quickly.
I need more information. What do you want reversed,
revision 2.253
date: 2001/09/23 03:39:01; author: momjian; state: Exp; lines: +3 -3
Peter Eisentraut [EMAIL PROTECTED] writes:
Shouldn't there be some form of CREATE TABLE AS / WITHOUT OIDS?
I thought about that, but decided it wasn't worth cluttering the
parsetree representation with yet another CreateAs/SelectInto hack.
regards, tom lane
...
Are you subscribed to general?
...
Everyone thought LIMIT # OFFSET # was preferred.
I think Hiroshi's point is the same as mine: discussions of feature
changes need to happen on -hackers before being implemented.
Subscriptions to other mailing lists should not be required to stay up
with
I don't think that enough votes are needed to reverse
the change. You broke the discussion first rule.
Are you subscribed to general? We had a big discussion there and there
was almost universal agreement that the LIMIT #,# syntax is too
error-prone, and the only reason to have it was for
OK, then why did Tom tell me to have the discusion on general? Don't we
ask the general users about user-visible feature removal? The is not an
implementation issue but a simple, What do users want? I agree it
would be good on hacker too, but how do we have a discussion on both?
...
Are
Dear all,
I am trying to install PostgreSQL 7.1.3 on Win98 with APACHE
and PHP (both installed and running), and
am getting errors with make and make install (see below).
What are the differences in installations for Win98, WinNT and Win2000?
There are so many procedures around and none is
54 matches
Mail list logo
