Re: [HACKERS] Documentation on page files

On Sat, 20 Apr 2002, Tom Lane wrote: > Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > > Chapter 7 of the Developers guide in about the Page Format on disk and it's > > a little out of date not to mention somewhat incomplete. > > Indeed, this seems to have very little relation to reality :-(

Re: [HACKERS] On-disk Tuple Size

On Sat, 20 Apr 2002, Tom Lane wrote: > Curt Sampson <[EMAIL PROTECTED]> writes: > > While we're at it, would someone have the time to explain to me > > how the on-disk CommandIds are used? > > To determine visibility of tuples for commands within a transaction. > Just as you don't want your trans

Re: [HACKERS] Schema (namespace) privilege details

On Sat, 20 Apr 2002, Sander Steffann wrote: > > > Maybe to keep hostile users from filling up your disk? Actually, I was serious, not sarcastic, about that "maybe." Like Tom, I'm not entirely sure that it's necessary to add this complexity, because there are so many other ways to abuse the syste

Re: [HACKERS] [INTERFACES] sqlbang

[EMAIL PROTECTED] writes: > The most reason for patch are paremeters, Parameters already exist: peter ~$ cat test.sql \echo :x1 \echo :x2 peter ~$ pg-install/bin/psql -f test.sql -v x1=foo -v x2=bar foo bar -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast

Re: [HACKERS] [INTERFACES] sqlbang

Nobody interested? I prepare my ISP Management System (ispms) to publish and want reduce number of patches needed to install it. SQLbangs widely ised in it: 0cicuta~(1)>grep -r '^#\!/usr/local/bin/psql' /usr/local/libexec/ispms | wc -l 61 The most reason for patch are paremeters, because w

Re: [HACKERS] Schema (namespace) privilege details

Hi, > Curt Sampson <[EMAIL PROTECTED]> writes: > > On Fri, 19 Apr 2002, Sander Steffann wrote: > >> I can't think of a reason that [creation of] temp tables should > >> be prevented. > > > Maybe to keep hostile users from filling up your disk? > > That does come to mind --- but if you've let host

Re: [HACKERS] Foreign keys and indexes.

> Of course, since Trigger on A depends on A we also have > Trigger on A -> B.id Should read: Trigger on A -> relation A Triggers depend on relation which owns it :) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send a

[HACKERS] Foreign keys and indexes.

In order to apply a dependency of foreign keys against a column set the most obvious way to go is via the unique index which in turn depends on the expected columns. A(id) -> B(id) A.id -> Foreign key -> Index on B.id -> B.id If B.id is dropped it'll cascade forward. The trick? Foreign keys

Re: [HACKERS] Improved scanner performance

BTW, here is what I get on an HP box for the same test you described (a dozen trivial SELECTs using string literals between 5MB and 10MB long), using latest sources: % cumulative self self total time seconds secondscalls ms/call ms/call name 47.5

Re: [HACKERS] syslog support by default

Tatsuo Ishii <[EMAIL PROTECTED]> writes: > I have removed the --enable-syslog option. Now as far as the system > has syslog(), the syslog support code is always in the build. > If this seems ok, I will update the doc. Seems reasonable. It might be a good idea for configure to verify that the he

Re: [HACKERS] syslog support by default

> Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > In my understanding we are going to turn on the --enable-syslog > > *configure* option by default (or remove the configuration option > > completely), but not change the syslog option in postgresql.conf > > (currently default to 0: that means not outp

[HACKERS] Implement a .NET Data Provider

Hi all. I'd like to implement a .NET Data provider for postgresql using the protocol as specified in . I think this is important because there are many sites out there that would be using ASP.NET and a postgresql database backend. I

Re: [HACKERS] Improved scanner performance

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Here's a breakdown of the postmaster file sizes and the wall-clock run > time of the long-literal test: > no options1749912 1m58.688s > -CFe 1754315 1m49.223s > -CF 1817621 1m43.780s > -CFa 1890

Re: [HACKERS] Improved scanner performance

Tom Lane writes: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Tom Lane writes: > >> I had the idea that -CF would enlarge the lexer tables quite a bit --- > >> what's the change in executable size?) > > > +150 kB > > > I've also looked at -CFe, which is supposedly the next slowest level, bu

Re: [HACKERS] Documentation on page files

Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > Chapter 7 of the Developers guide in about the Page Format on disk and it's > a little out of date not to mention somewhat incomplete. Indeed, this seems to have very little relation to reality :-(. I didn't even realize that we had such a desc

Re: [HACKERS] On-disk Tuple Size

Curt Sampson <[EMAIL PROTECTED]> writes: > While we're at it, would someone have the time to explain to me > how the on-disk CommandIds are used? To determine visibility of tuples for commands within a transaction. Just as you don't want your transaction's effects to become visible until you comm

Re: [HACKERS] On-Disk Tuple Size

Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > Well, from my examination of the on-disk data the CTID stored there is the > same as its location in the file, so it could just be filled in while > reading. Nope. CTID is used as a forward link from an updated tuple to its newer version.

[HACKERS] Documentation on page files

[Please CC any replies, I'm subscribed nomail] Hi, Chapter 7 of the Developers guide in about the Page Format on disk and it's a little out of date not to mention somewhat incomplete. 1. Is there documentation elsewhere (other than the source)? 2. If not, would patches be accepted to correct t

Re: [HACKERS] commands subdirectory continued -code cleanup

On Fri, 2002-04-19 at 20:38, Fernando Nasser wrote: > John Gray wrote: > > > > and two macros: > > > > RECURSE_OVER_CHILDREN(relid); > > AlterTableDoSomething(childrel,...); > > RECURSE_OVER_CHILDREN_END; > > > > (this seems more straightforward than passing the text of the function > > call as

Re: [HACKERS] commands subdirectory continued -code cleanup

On Fri, 2002-04-19 at 20:34, Tom Lane wrote: > John Gray <[EMAIL PROTECTED]> writes: > > Sequences still seem to work after they've had attributes renamed, but I > > see little value in being able to do this. Is it OK to prohibit the > > renaming of sequence columns? > > That seems like an error

Re: [HACKERS] On-Disk Tuple Size

On Sat, Apr 20, 2002 at 05:22:20PM +0900, Curt Sampson wrote: > > ...and 6 bytes for the CTID, which I guess may be unnecessary. > > Really? How would things work without it? Well, from my examination of the on-disk data the CTID stored there is the same as its location in the file, so it could

Re: [HACKERS] On-Disk Tuple Size

[Moved from general to -hackers.] On Sat, 20 Apr 2002, Martijn van Oosterhout wrote: > > In MS SQL server, for example > > Where is the information needed to determine visibility for transactions? In > Postgres that's at least 16 bytes (cmin,cmax,xmin,xmax). How does SQL server > do that? S

[HACKERS] On-disk Tuple Size

[I've moved this discussion about changing the line pointer from four bytes to two from -general to -hackers, since it's fairly technical. The entire message Tom is responding to is appended to this one.] On Sat, 20 Apr 2002, Tom Lane wrote: > Curt Sampson <[EMAIL PROTECTED]> writes: > > ... The