On Wed, 2002-09-18 at 05:02, Bruce Momjian wrote:
> Oliver Elphick wrote:
> > I'm unhappy because I know that I will get bug reports that I will have
> > to deal with. They will take time and effort and would not be necessary
> > if we had a seamless upgrade path.
>
> This last line gave me a ch
> Change log_min_error_statement to be off by default (Gavin)
I will be happy to provide this simple fix once I can get some indication
of the preferred implication. The discussion left off with Bruce prefering
that the GUC code for the *_min_* variables be variable specific where as
Tom saw no n
On Wednesday 18 September 2002 12:55 am, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Not talking about a freeze. Talking about separation of system/feature
> > metadata from user metadata that wouldn't change in the upgrade anyway --
> But the system catalogs *store* that metada
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, do you want any TODO items from this?
I think we have plenty already on this general subject, no? But you
could stick this whole thread into TODO.detail/typeconv if you like.
(It's interesting to compare these ideas to where we were 2 years
ago...
I have copied Tom's fine email to:
http://www.ca.postgresql.org/docs/momjian/upgrade_7.3
and have added a mention of it in the HISTORY file:
A dump/restore using "pg_dump" is required for those wishing to migrate
data from any previous release. A summary of changes needed in cli
There has been a lot of activity on open items in the past week. Here
is the updated list.
Basically, upgrading and casting have blown up into a variety of items.
---
P O S T G R E S Q L
Tom, do you want any TODO items from this?
---
Tom Lane wrote:
> I started by saying
> > * Within a category, "up" (lossless) conversions are implicit, "down"
> > (potentially lossy) conversions should be assignment-only.
>
Jan Wieck wrote:
> "Nigel J. Andrews" wrote:
> > However, how is that going to work if tablespaces are introduced in 7.4. Surely
> > the same mechanism for tablespaces would be used for pg_xlog. As the tablespace
> > mechanism hasn't been determined yet, as far as I know, wouldn't it be best to
>
Lamar Owen <[EMAIL PROTECTED]> writes:
> On Tuesday 17 September 2002 11:51 pm, Tom Lane wrote:
>> The bald fact of the matter is that we are still a good ways away from
>> the point where we might be willing to freeze the system catalogs.
> Not talking about a freeze. Talking about separation
"Nigel J. Andrews" wrote:
> However, how is that going to work if tablespaces are introduced in 7.4. Surely
> the same mechanism for tablespaces would be used for pg_xlog. As the tablespace
> mechanism hasn't been determined yet, as far as I know, wouldn't it be best to
> see what happens there be
Bruce Momjian wrote:
>
> Dave Page wrote:
> > Which in this case is what puzzles me. We are only talking about a
> > simple GUC variable after all - I don't know for sure, but I'm guessing
> > it's not a huge effort to add one?
>
> Can we get agreement on that? A GUC for pg_xlog location? Much
On Tuesday 17 September 2002 11:51 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> >> How does pg_upgrade work?
> > [ pretty good description ]
> You missed a key point, which is that pg_upgrade does not even try to
> cope with version-to-version system catalog changes. It assumes
On Tuesday 17 September 2002 11:22 pm, Bruce Momjian wrote:
> This is a better description tha[n] I could make. If you look at the
> script it is very well commented so you should be able to see it works.
> Also, read the manual page first.
I don't know how, but this time looking at the script, I
Tom Lane wrote:
> > But I am not
> > sure how to find out what the execution plan is for a prepared
> > statement, since EXPLAIN doesn't work for a prepared statement (i.e.
> > EXPLAIN EXECUTE , doesn't work).
>
> Hmmm --- I can see the usefulness of that, but it looks like a new
> feature and he
Does pl/python even have a DECLARE section that can mimick the data type
of an existing table column?
---
Greg Copeland wrote:
-- Start of PGP signed section.
> Does anyone know if such effort is also required to pl/python
Oliver Elphick wrote:
> On Tue, 2002-09-17 at 21:40, Tom Lane wrote:
> > In short, I'm not sure why you and Oliver are so unhappy. We may not
> > have made the world better than before for upgrade scenarios, but I
> > don't think we've made it worse either.
>
> I'm unhappy because I know that I
On Wed, 2002-09-18 at 04:22, Bruce Momjian wrote:
>
> In summary, doing any kind of data changes is quite involved (smaller
> tuple header for 7.3) and because it has to be redone for every release,
> it is quite a pain.
Is it feasible to make a utility to rewrite each table, shortening the
hea
Lamar Owen <[EMAIL PROTECTED]> writes:
>> How does pg_upgrade work?
> [ pretty good description ]
You missed a key point, which is that pg_upgrade does not even try to
cope with version-to-version system catalog changes. It assumes it can
use pg_dump to dump and reload the database schema. So t
On Tue, 2002-09-17 at 21:40, Tom Lane wrote:
> In short, I'm not sure why you and Oliver are so unhappy. We may not
> have made the world better than before for upgrade scenarios, but I
> don't think we've made it worse either.
I'm unhappy because I know that I will get bug reports that I will h
>
> I'd give up a few extensibility features for solid upgrading. If
> I didn't
> have so much invested in PostgreSQL I might take a hard look at MySQL 4,
> since data migration has heretofore been one of their few real
> strengths.
> But I've got three years of RPM maintenance and five years of
This is a better description that I could make. If you look at the
script it is very well commented so you should be able to see it works.
Also, read the manual page first.
In summary, doing any kind of data changes is quite involved (smaller
tuple header for 7.3) and because it has to be redo
On Tuesday 17 September 2002 10:27 pm, Christopher Kings-Lynne wrote:
> Lamar Owen wrote:
> > Sorry, it's just a sore spot for me, this whole
> > upgrade issue.
> IS there any solution to Postgres's upgrade problems? I mean, ever? With
> the complex catalog design, etc - how is it every possibl
> > How does pg_upgrade work?
>
> pg_upgrade sort of worked for 7.2 but I got to it too late and I didn't
> properly expand the pg_clog files. In 7.3, the file format has changed.
> If we don't change the format for 7.4, I can do it, but I have to add
> schema stuff to it. Shouldn't be too hard
Christopher Kings-Lynne wrote:
> > I just want people to not get bit in a bad way and decide they
> > don't want to
> > use PostgreSQL after all. And with the new features of 7.3, lots
> > of users
> > who might have begun with 7.2 are going to want to upgrade -- but
> > if it's too
> > painful..
> I just want people to not get bit in a bad way and decide they
> don't want to
> use PostgreSQL after all. And with the new features of 7.3, lots
> of users
> who might have begun with 7.2 are going to want to upgrade -- but
> if it's too
> painful Sorry, it's just a sore spot for me, this
On Tuesday 17 September 2002 04:40 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > ... What I am looking
> > at is whether the user will have to run 7.3's pg_dump in order to migrate
> > older data.
> AFAIK this is not *necessary*, though it may be *helpful*. Aside from
> the OP
Hi,all expert of the postgresql.
I want to learn the kernel of postgresql. When I debug it with gdb, I
come to a problem that I can't solve. In the BackendStartup() it forks a new
child process. I can't trace into the new child process with attach. It say that
Operation is not permitte
> * A reloaded dump will not create dependencies between serial columns
> and sequence objects, nor between triggers and foreign key
> constraints, thus 7.3's nifty new support for DROP CONSTRAINT won't
> work, nor will dropping a table make its associated sequences go away.
> However, thi
> When I say that the second form of CREATE TYPE allow you to make
> RECORD type
> like RECORD, i don't want to speak about the record in PlPgsql but RECORD
> from programming language like ADA or C (typedef struct).
>
> So the real question is:
> Can I use this new type like other user-type ?
> C
Rod Taylor wrote:
> I forget, is it possible to make a GUC that cannot be changed during
> runtime?
Yes, you can set it to it only can be changed by the super-user and only
takes effect on restart.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
I forget, is it possible to make a GUC that cannot be changed during
runtime?
If so, then I vote yes, otherwise, there is a problem if someone tries.
On Tue, 2002-09-17 at 17:07, Bruce Momjian wrote:
> Dave Page wrote:
> > Which in this case is what puzzles me. We are only talking about a
> > s
Nigel J. Andrews wrote:
> On Tue, 17 Sep 2002, Bruce Momjian wrote:
>
> > Dave Page wrote:
> > > Which in this case is what puzzles me. We are only talking about a
> > > simple GUC variable after all - I don't know for sure, but I'm guessing
> > > it's not a huge effort to add one?
> >
> > Can w
"Nigel J. Andrews" wrote:
> However, how is that going to work if tablespaces are introduced in 7.4. Surely
> the same mechanism for tablespaces would be used for pg_xlog. As the tablespace
> mechanism hasn't been determined yet, as far as I know, wouldn't it be best to
> see what happens there b
On Tue, 17 Sep 2002, Bruce Momjian wrote:
> Dave Page wrote:
> > Which in this case is what puzzles me. We are only talking about a
> > simple GUC variable after all - I don't know for sure, but I'm guessing
> > it's not a huge effort to add one?
>
> Can we get agreement on that? A GUC for pg_x
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > ... What I am looking
> > at is whether the user will have to run 7.3's pg_dump in order to migrate
> > older data.
>
> AFAIK this is not *necessary*, though it may be *helpful*. Aside from
> the OPAQUE issue, which we will fix one w
Dave Page wrote:
> Which in this case is what puzzles me. We are only talking about a
> simple GUC variable after all - I don't know for sure, but I'm guessing
> it's not a huge effort to add one?
Can we get agreement on that? A GUC for pg_xlog location? Much cleaner
than -X, doesn't have the p
> Using 7.3's pg_dump would help you with the GRANT issue, but AFAIR it
> won't do anything for reconstructing serial or foreign-key dependencies.
The below perl script can help with both of those.
http://www.rbt.ca/postgresql/upgrade/upgrade.tar.gz
Explanation URL:
http://www.rbt.ca/postgresql
On Tue, 2002-09-17 at 16:44, scott.marlowe wrote:
> Hey, me and a few other folks were having a discussion off list, and the
> subject of inserts and missing columns came up. you may remember the point
> in the "I'm done" post by Bruce. It said:
>
> > o -Disallow missing columns in INSERT ...
Hey, me and a few other folks were having a discussion off list, and the
subject of inserts and missing columns came up. you may remember the point
in the "I'm done" post by Bruce. It said:
> o -Disallow missing columns in INSERT ... VALUES, per ANSI
> > What is this, and why is it marked done
Lamar Owen <[EMAIL PROTECTED]> writes:
> ... What I am looking
> at is whether the user will have to run 7.3's pg_dump in order to migrate
> older data.
AFAIK this is not *necessary*, though it may be *helpful*. Aside from
the OPAQUE issue, which we will fix one way or another, I am aware of
t
Marc needs old PostgreSQL source code tarbals for our ftp site. We
have >= 6.1, and I have postgres95 1.01 and postgres 4.2. Does anyone
have 6.0.X and 1.0X?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your li
On Tuesday 17 September 2002 03:59 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > as yet. I would expect to be able to release an RPMset for beta 2 if
> > that is a week or two off.
> Given that we'll be forcing an initdb for beta2 anyway, those who use
> RPMs may be just as ha
Lamar Owen <[EMAIL PROTECTED]> writes:
> I have a basic build running, but it's not releasable. I haven't had time to
> go through it with the properly fine-toothed comb that I want to as yet. I
> would expect to be able to release an RPMset for beta 2 if that is a week or
> two off.
Sounds g
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I need a clarification. In the non-assignment case, does:
> WHERE numericcol = numericcol * 3.14159
> evaluate "numericcol * 3.14159" as a numeric?
Yup (given my proposed changes that is).
> And does:
> WHERE 5.55 = numericcol * 3.14159
>
Tom Lane wrote:
> Note that if you write, say,
> set numericcol = numericcol * 3.14159;
> my proposal would do the "right thing" since the constant would be typed
> as numeric to start with and would stay that way. To do what you want
> with a float variable, it'd be necessary to write
>
I started by saying
> * Within a category, "up" (lossless) conversions are implicit, "down"
> (potentially lossy) conversions should be assignment-only.
but as always the devil is in the details.
After further thought, and the thread with Andreas about where we might go
with this in 7.4, I have d
Tom Lane wrote:
> I favor using IMPLICIT, which would make the syntax of CREATE CAST be
>
> CREATE CAST (sourcetype AS targettype)
> WITH FUNCTION funcname (argtype)
> [ AS ASSIGNMENT | IMPLICIT ]
>
> CREATE CAST (sourcetype AS targettype)
> WITHOUT FUNCTION
>
Having not seen anyone asking about the progress on the 7.3beta RPMset, I
thought I would give a statement as to where things stand.
I am waiting the result of the pg_dump from 7.2.x to 7.3 restore discussion.
The structure of the entire packaging depends upon knowing how the upgrade
will be
On Monday 16 September 2002 01:15 pm, Andrew Sullivan wrote:
> On Fri, Sep 13, 2002 at 03:28:12PM +1000, Justin Clift wrote:
> > Afilias and LibertyRMS, the people who've been happily running the
> > .info namespace on PostgreSQL servers, are the technical backend of
> > the ISOC application for m
I wrote:
> I think we must extend pg_cast's castimplicit column to a three-way value:
> * okay as implicit cast in expression (or in assignment)
> * okay as implicit cast in assignment only
> * okay only as explicit cast
> Question: what shall we call these alternatives in CREAT
"Jerome Chochon" <[EMAIL PROTECTED]> writes:
> Can I use this new type like other user-type ?
> CREATE TABLE person (his_name VARCHAR, his_adress adress);
> ...where adress is CREATE TYPE adress AS (number int, street text, country
> VARCHAR);
Not at the moment, though that might be an interestin
Hi Gavin,
Thnx for your response...
Maybe you know how to check memory on an Ultrasparc-II???
Cheers!
Wim.
Gavin Sherry wrote:
>On Tue, 17 Sep 2002, Wim wrote:
>
>
>
>>Hello guys,
>>
>>I have still problems with dumping my database
>>
>>
>
>Wim,
>
>This kind of error is not generat
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> 2. Allow implicit up-coercion int2->int4->int8->numeric->float4->float8,
>> but down-coercions aren't implicit except for assignment.
> How about int2->int4->int8->numeric->float4->float8->numeric ?
> That would also allow an upward path
Hi,
I just talked to Sebastian again and we face another problem. The
software he's porting to PostgreSQL calls SQLProcedureColumns to get the
info about the input columns and the result. But the problem is that the
function in question returns an unnamed cursor. Before we start porting
the proce
On Tue, 17 Sep 2002, Wim wrote:
>
>
> Hello guys,
>
> I have still problems with dumping my database
Wim,
This kind of error is not generated as a result of on-disk data
corruption. It is probably a hardware error: memory, cache, or CPU. Can
you replace any of these components on the mac
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> It is not sufficient for the optimizer for joins though, since it
> cannot use the int4 index when confronted with "where tab1.int4col =
> tab2.numericcol".
For cross-datatype joins, the proposal as I sketched it would result in
the parser
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> When those are really truncated ESQL/C needs to set a warning in sqlca.sqlwarn
> though, thus I think the second signature should also have an output flag to tell
> whether truncation actually occurred.
> Maybe this should be kept for a pr
On Mon, 2002-09-16 at 17:54, Tom Lane wrote:
> In CVS tip:
>
> regression=# create domain nnint int not null;
> CREATE DOMAIN
Ok, I'll take a look at this today.
Thanks
--
Rod Taylor
---(end of broadcast)---
TIP 1: subscribe and unsubscribe
Sorry if my english is not very good. ;-).
When I say that the second form of CREATE TYPE allow you to make RECORD type
like RECORD, i don't want to speak about the record in PlPgsql but RECORD
from programming language like ADA or C (typedef struct).
So the real question is:
Can I use this new
Hi all,
I have a problem with inserting one milling records into a table using a
function. This is for testing. The backend crashes on that every time,
although the error messages seem to be different. Can I post a full
description here or should that go to pgsql-general?
Thanks.
Best Regards,
Hi Jerome,
The RECORD type is used for writing stored procedures and functions that
return sets.
eg. CREATE FUNCTION foo() RETURNS setof adress
AS '...';
Sort of thing...
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jerome Chochon
Sent: Tuesd
Hi all.
I have read the last version of PostgreSQL (7.3
beta) and found that the second version of CREATE TYPE is very
interesting.
So we can create a type that look like a
RECORD.
For example:
CREATE TYPE adress AS (number int, street text,
country VARCHAR);
But can i use this type in
> > For numbers there is probably only the solution to invent an
> > "anynumber" generic type.
>
> Actually, I had been toying with the notion of doing the following:
>
> 1. A numeric literal is initially typed as the smallest type that will
> hold it in the series int2, int4, int8, numeric (no
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
> Sent: 17 September 2002 09:49
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] PGXLOG variable worthwhile?
>
>
> Users HAVE provided their feedback - they want P
> Let's leave it. The main point to focus postgres on unix is not
> only because
> unix is proven/known as robust and scalable, but unix is much
> more standard to
> support across multiple OS. The amount with which windows differs
> from unices
> on API level, any serious efforts to make postgres
> -Original Message-
> From: Shridhar Daithankar
> [mailto:[EMAIL PROTECTED]]
> Sent: 17 September 2002 09:30
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] PGXLOG variable worthwhile?
>
>
> On 17 Sep 2002 at 16:11, Christopher Kings-Lynne wrote:
>
> But I
> I think there is some confusion here. The runtime checks Andreas was
> talking about was allowing a double of 64.0 to cast to an int4 while
> disallowing 64.1 from being cast to an int4 because it is not a hole
> number.
Yes, and Tom's proposal for numbers is sufficient for constants, since
> -Original Message-
> From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]]
> Sent: 17 September 2002 09:05
> To: Dave Page; Bruce Momjian
> Cc: Robert Treat; Justin Clift; Peter Eisentraut; Tom Lane;
> Curt Sampson; PostgreSQL Hackers Mailing List
> Subject: RE: [HACKERS] PGXLOG v
On 17 Sep 2002 at 16:11, Christopher Kings-Lynne wrote:
> > What I can't understand is the attitude of some people here. Yes,
> > Microsoft are evil, but the bottom line is, millions of people use
> > Windows. Just look at the number of downloads for pgAdmin (shown at
> > http://www.pgadmin.org/d
Hello guys,
I have still problems with dumping my database
I have postgres 7.2.1 running on a solaris 8 server. When I try to do a
pg_dump of my database, I get the following message:
pg_dump: query to obtain list of tables failed: server closed the
connection unexpectedly
This p
> What I can't understand is the attitude of some people here. Yes,
> Microsoft are evil, but the bottom line is, millions of people use
> Windows. Just look at the number of downloads for pgAdmin (shown at
> http://www.pgadmin.org/downloads/) - the last stable version has clocked
> up over 38,000
> I use PostgreSQL on Linux for production and XP for development, and am
> likely to continue that way. I've been beta testing the native Win32
> port of PostgreSQL as Justin has and the latest version is fantastic -
> it runs as a service, osdb shows impressive results compared to Cygwin
> Postg
> What I will do instead is adjust parse_coerce.c so that a
> length-coercion function can have either of the signatures
> foo(foo,int4) returns foo
> or
> foo(foo,int4,bool) returns foo
> and then modify the above-mentioned length coercion functions to provide
> the desired behavior.
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 17 September 2002 06:36
> To: Christopher Kings-Lynne
> Cc: Robert Treat; Justin Clift; Peter Eisentraut; Tom Lane;
> Curt Sampson; PostgreSQL Hackers Mailing List
> Subject: Re: [HACKERS] PGXLOG variable wor
74 matches
Mail list logo
