On Fri, 5 Jul 2002, Curt Sampson wrote:
>
> While there are big changes between 7.2 and the next release, they
> aren't really any bigger than others during the 7.x series. I don't
> really feel that the next release is worth an 8.0 rather than a 7.3. But
> this is just an opinion; it's not somet
On Fri, 5 Jul 2002, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Actually, the "big" change is such that will, at least as far as I'm
> > understanding it, break pretty much every front-end applicaiton ...
>
> Only those that inspect system catalogs --- I'm not sure what p
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Actually, the "big" change is such that will, at least as far as I'm
> understanding it, break pretty much every front-end applicaiton ...
Only those that inspect system catalogs --- I'm not sure what percentage
that is, but surely it's not "pretty
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Syntax proposal:
> CREATE CONVERSION
>SOURCE
>DESTINATION
>FROM
Doesn't a conversion currently require several support functions?
How much overhead will you be adding to funnel them all through
one function?
Basically I'd lik
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Doesn't a conversion currently require several support functions?
>> How much overhead will you be adding to funnel them all through
>> one function?
> No, only one function is sufficient. What else do you think of?
I see two different functions linked
> > CREATE CONVERSION
> >SOURCE
> >DESTINATION
> >FROM
>
> Doesn't a conversion currently require several support functions?
> How much overhead will you be adding to funnel them all through
> one function?
No, only one function is sufficient. What else do you think o
Fix typo in xl_heaptid comment
Servus
Manfred
--- ../base/src/include/access/htup.h 2002-07-04 18:05:04.0 +0200
+++ src/include/access/htup.h 2002-07-05 16:52:44.0 +0200
@@ -268,15 +268,15 @@
/*
* When we insert 1st item on new page in INSERT/UPDATE
* we can (and we do)
On Fri, Jul 05, 2002 at 12:39:13PM -0400, Lamar Owen wrote:
> One other usability note: why can't postmaster perform the steps of
> an initdb if -D points to an empty directory? It's not that much
> code, is it? (I know that one extra step isn't backbreaking, but
> I'm looking at this from a ra
As the upcoming release is breaking compatibility anyway: what do you
think about placing a magic number and some format version info into
the page header?
One 32-bit-number per page should be enough to encode page type and
version. We have just to decide, how we want it:
a) combine page type
> I see two different functions linked to from each pg_wchar_table
> entry... although perhaps those are associated with encodings
> not with conversions.
Yes. those are not directly associated with conversions.
> IIRC the existing conversion functions deal in C string pointers and
> lengths. I
Bruce Momjian wrote:
> You are saying, "How do we know what WAL records go with that backup
> snapshot of the file?" OK, lets assume we are shutdown. You can grab
> the WAL log info from pg_control using contrib/pg_controldata and that
> tells you what WAL logs to roll forward when you need to P
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> What happens if I drop an inherited column in a child table? Maybe it
>> works, but what happens when I SELECT the column in the parent table?
> Well, what happens if you rename a column in a child table? Same problem?
Ideally we should
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> 1. I'm going to prevent people from dropping the last column in their table.
> I think this is the safest option. How do I check if there's any other non
> dropped columns in a table? Reference code anywhere?
You look through the Relation'
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> So, say the 'b' column is renamed to 'dropped_2', then you can do this:
> select dropped_2 from tab;
> select tab.dropped_2 from tab;
> update tab set dropped_2 = 3;
> select * from tab where dropped_2 = 3;
> Where have I missed the COLUMN_
> Let me re-write it, and I'll post it in the next version. The section
> dealt with what to do when you have a valid restored controlfile from a
> backup system, which is in the DB_SHUTDOWNED state, and that points to a
> valid shutdown/checkpoint record in the log; only the checkpoint record
>
I modified pg_controldata to display a few new fields. Example output
appears at the end of this message, and the cvs log is:
Add a few new lines to display recently added fields in the ControlFile
structure.
Now includes the following new fields:
integer/float date/time storage
maximum lengt
On Wednesday 03 July 2002 12:09 pm, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > AFAIK I can run as many backends as I like (up to some practical limit)
> > on the same comuter at the same time, as long as they use different
> > ports and different data directories.
> We don't have an automate
> Actually, the "big" change is such that will, at least as far as I'm
> understanding it, break pretty much every front-end applicaiton ... which,
> I'm guessing, is pretty major, no? :)
I've always thought of our release numbering as having "themes". The 6.x
series took Postgres from interestin
On Fri, 5 Jul 2002, Thomas Lockhart wrote:
> > Actually, the "big" change is such that will, at least as far as I'm
> > understanding it, break pretty much every front-end applicaiton ... which,
> > I'm guessing, is pretty major, no? :)
>
> I've always thought of our release numbering as having "
Christopher Kings-Lynne wrote:
> OK,
>
> This is the problem I'm having with the DROP COLUMN implementation. Since
> I've already incorporated all of Hiroshi's changes, I think this may have
> been an issue in his trial implementation as well.
>
> I have attached my current patch, which works f
Marc G. Fournier wrote:
> On Fri, 5 Jul 2002, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > Actually, the "big" change is such that will, at least as far as I'm
> > > understanding it, break pretty much every front-end applicaiton ...
> >
> > Only those that inspect s
Tatsuo Ishii wrote:
> Here is my proposal for new CREATE CONVERSION which makes it possible
> to define new encoding conversion mapping between two encodings on the
> fly.
>
> The background:
>
> We are getting having more and more encoding conversion tables. Up to
> now, they reach to 385352 so
Lamar Owen wrote:
> On Wednesday 03 July 2002 12:09 pm, Bruce Momjian wrote:
> > Hannu Krosing wrote:
> > > AFAIK I can run as many backends as I like (up to some practical limit)
> > > on the same comuter at the same time, as long as they use different
> > > ports and different data directories.
J. R. Nield wrote:
> On Fri, 2002-07-05 at 01:42, Bruce Momjian wrote:
> >
> > We have needed
> > point-in-time recovery for a long time,
>
> Most thanks should go to vadim (and whoever else worked on this), since
> his WAL code already does most of the work. The key thing is auditing
> the bac
On Fri, 2002-07-05 at 17:39, Lamar Owen wrote:
> No, what I envisioned was a standalone dumper that can produce dump output
> without having a backend at all. If this dumper knows about the various
> binary formats, and knows how to get my data into a form I can then restore
> reliably, I will
In my book, schema support is a big thing, leading to rethink a lot of
database organization and such. PostgreSQL 8 would stress this
importance.
--
Alessio F. Bragadini[EMAIL PROTECTED]
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone
The problem is that the new column is now part of pg_attribute so every
catalog/pg_attribute.h DATA() line has to be updated. Did you update
them all with 'false' in the right slot? Not sure what the chunks are.
---
Chri
> > Well, what happens if you rename a column in a child table?
> Same problem?
>
> It merrily renames the column in the child table (I tried it). When
> SELECTing the parent, bogus data appears. Looks like a bug to me.
> Maybe the ALTER TABLE ... RENAME COLUMN code should check for inherite
Rod Taylor wrote:
> > We could change pg_attribute to another name, and create a view called
> > pg_attribute that never returned isdropped columns to the client. That
> > would allow clients to work cleanly, and the server to work cleanly.
>
> Another case where having an informational schema w
On generic recovery...
What is wrong with this strategy...
0. Put the database in single user mode.
1. Dump the Schema, with creation order properly defined, and with all
constraints written to a separate file. (IOW, one file contains the
bare tables with no index, constraint or trigger stuff,
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Manfred Koizar wrote:
> Fix typo in xl_heaptid
Manfred Koizar wrote:
> As the upcoming release is breaking compatibility anyway: what do you
> think about placing a magic number and some format version info into
> the page header?
>
> One 32-bit-number per page should be enough to encode page type and
> version. We have just to decide, how
There was an interesting thread/process discussion in the gproff
Slashdot discussion:
http://slashdot.org/article.pl?sid=02/07/05/1457231&mode=nested&tid=106
This guy had interesting comments:
http://slashdot.org/~pthisis/
Especially this comment:
http://slashdot.org/c
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 05, 2002 7:59 PM
> To: PostgreSQL-development
> Subject: [HACKERS] Thread discussion
>
>
> There was an interesting thread/process discussion in the gproff
> Slashdot discussion:
>
>
> http
Dann Corbit wrote:
> Especially this comment:
>
> http://slashdot.org/comments.pl?sid=35441&cid=3829377
>
> ==
> Which is pretty much pointless MS bashing and incorrect.
Is there such a thing. ;-)
Anyway, the analysis of So
35 matches
Mail list logo
