hello
there is an alternate sql server, designed almost for your needs, it's
name is SQLite. it's a very simple one, but you can statically compile it
into your programs. search sf or freshmeat for it(or google, ofcourse)
Bye,
Gergely Czuczy
mailto: [EMAIL PROTECTED]
PGP: http://phoemix.harmless
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is our maximum table size limited by the maximum block number?
Certainly.
> Is the 16TB number a hold-over from when we weren't sure block number
> was unsigned, though now we are pretty sure it is handled as unsigned
> consistenly?
It's a holdover. A
Is our maximum table size limited by the maximum block number?
With our block number maximum of:
#define MaxBlockNumber ((BlockNumber) 0xFFFE)
0xFFFE = 4294967294
would the max table size really be (4GB * 8k) or 32 TB, not 16TB, as
listed in the FAQ:
"Jenny -" <[EMAIL PROTECTED]> writes:
>> TupleTables are just temporary data structures to hold transiently
>> created tuples during execution of a query. There's usually one for
>> each plan node.
> The TupleTable will exist for the query from the point the query is made
> untill the transactio
TupleTables are just temporary data structures to hold transiently
created tuples during execution of a query. There's usually one for
each plan node.
So, if i have the following transaction:
begin work;
select * from students where a age=19 for update;
lock table studens in share mode;
commit;
Th
Tom wrote...
> At this point it should move to pghackers, I think.
Background for pghackers first, open issues below...
Over on pgpatches we've been discussing ISO syntax for
time intervals of the format with time-unit designators.
http://archives.postgresql.org/pgsql-patches/2003-0
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assume MODIFY would allow you to alter the constraint without
> > re-checking all the rows, as would be required by DROP/ADD. However, if
> > you are modifying the constraint, wouldn't we have to recheck all the
> > rows anyway.
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oh, you bring up two important issues --- one is is the gap in time
> between the drop and the recreate. This case can be done by
> doing the query in a transaction --- the lock will exist until the
> transaction completes, and in fact, you can roll it b
Bruce Momjian wrote:
> Manfred Spraul wrote:
> > Jeroen Ruigrok/asmodai wrote:
> >
> > >-On [20030908 23:52], Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> > >
> > >
> > >>Why would FreeBSD have a "library of thread-safe libc functio
Manfred Spraul wrote:
> Jeroen Ruigrok/asmodai wrote:
>
> >-On [20030908 23:52], Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> >
> >
> >>Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
> >>if the functi
Jeroen Ruigrok/asmodai wrote:
> -On [20030908 22:42], Bruce Momjian ([EMAIL PROTECTED]) wrote:
> >I assume MODIFY would allow you to alter the constraint without
> >re-checking all the rows, as would be required by DROP/ADD. However, if
> >you are modifying the constraint
Greg Stark <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> I think the percentage of deployments that enable assertions (which
>> causes a runtime performance hit) but NOT debugging info (which does
>> not) is pretty small.
> How big a penalty is it? If it's small, or if i
Jeroen Ruigrok/asmodai wrote:
-On [20030908 23:52], Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
if the functions weren't thread-safe? I think the test is faulty.
A thread-safe library has a per-thr
-On [20030908 23:52], Peter Eisentraut ([EMAIL PROTECTED]) wrote:
>Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
>if the functions weren't thread-safe? I think the test is faulty.
Having libc_r is not a guarantee that all functions of libc ar
Bruce Momjian writes:
> > Both gethostbyname() and getpwuid() have no _r equivalents on
> > FreeBSD-STABLE, ergo no thread-safe functions of these.
>
> So you don't have all the *_r functions, and your non-*_r functions
> aren't thread-safe. Should we disable theading on FreeBSD? Seems so.
Why
Neil Conway <[EMAIL PROTECTED]> writes:
> I think the percentage of deployments that enable assertions (which
> causes a runtime performance hit) but NOT debugging info (which does
> not) is pretty small.
How big a penalty is it? If it's small, or if it could be made small by making
a few assert
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assume MODIFY would allow you to alter the constraint without
> > re-checking all the rows, as would be required by DROP/ADD. However, if
> > you are modifying the constraint, wouldn't we have to recheck all th
"Jeroen Ruigrok/asmodai" <[EMAIL PROTECTED]> wrote:
> Because what I can imagine, and please correct me if I miss something in
> my thought pattern, you have a small gap between dropping a constraint
> and adding the new one allowing the possibility of missing checks.
I think, someone correct me i
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
What's the practice in deprecating other "features"?
We generally don't ;-). Certainly 7.4 contains bigger incompatible
changes than this one, and so have most of our prior releases.
I thought I had seen discussions along the l
Doug McNaught <[EMAIL PROTECTED]> writes:
> ivan <[EMAIL PROTECTED]> writes:
>> ist possible to compile postgres (after same small modification) to shared
>> so, or dll , and usr it like normal postgres , but without any server and
>> so on.
> Not without very major code changes.
... which are un
Jeroen Ruigrok/asmodai <[EMAIL PROTECTED]> writes:
> Because what I can imagine, and please correct me if I miss something in
> my thought pattern, you have a small gap between dropping a constraint
> and adding the new one allowing the possibility of missing checks.
If you're concerned about conc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I assume MODIFY would allow you to alter the constraint without
> re-checking all the rows, as would be required by DROP/ADD. However, if
> you are modifying the constraint, wouldn't we have to recheck all the
> rows anyway.
Yeah. Rod's point about alt
-On [20030908 22:42], Bruce Momjian ([EMAIL PROTECTED]) wrote:
>I assume MODIFY would allow you to alter the constraint without
>re-checking all the rows, as would be required by DROP/ADD. However, if
>you are modifying the constraint, wouldn't we have to recheck all the
>rows a
ivan wrote:
hi,
ist possible to compile postgres (after same small modification) to shared
so, or dll , and usr it like normal postgres , but without any server and
so on. Its whould be work like simple database (with all funciton in one
lib), which dont need any others additionals like (network,
On Mon, 8 Sep 2003, Bruce Momjian wrote:
> Dann Corbit wrote:
> > Mingw uses the native Win32 libraries.
> >
> > Porting from a Mingw port to VC++ will be trivial compared to what we
> > have now.
> >
> > > where can I access latest dev source code and dev docs in
> > > the/from CVS ?
> >
> >
Tom Lane wrote:
> Jeroen Ruigrok/asmodai <[EMAIL PROTECTED]> writes:
> > can someone add:
> > Add an ALTER TABLE MODIFY CONSTRAINT
> > item to the todo list?
>
> Why? For a constraint, it's not obvious what this would do for you that
> dropping and re-adding the constraint wouldn't do. In the pl
ivan <[EMAIL PROTECTED]> writes:
> hi,
>
> ist possible to compile postgres (after same small modification) to shared
> so, or dll , and usr it like normal postgres , but without any server and
> so on.
Not without very major code changes.
-Doug
---(end of broadcast)---
hi,
ist possible to compile postgres (after same small modification) to shared
so, or dll , and usr it like normal postgres , but without any server and
so on. Its whould be work like simple database (with all funciton in one
lib), which dont need any others additionals like (network,other proces
Jeroen Ruigrok/asmodai <[EMAIL PROTECTED]> writes:
> can someone add:
> Add an ALTER TABLE MODIFY CONSTRAINT
> item to the todo list?
Why? For a constraint, it's not obvious what this would do for you that
dropping and re-adding the constraint wouldn't do. In the places where
we support CREATE O
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> How would we "deprecate" it exactly? Throw a NOTICE?
>>
> Release notes, I guess. A NOTICE would be fine as long as it didn't
> result in a flood of them. If that happened once at parse time that
> should be fine, I think.
It woul
Dann Corbit wrote:
> Mingw uses the native Win32 libraries.
>
> Porting from a Mingw port to VC++ will be trivial compared to what we
> have now.
>
> > where can I access latest dev source code and dev docs in
> > the/from CVS ?
>
> Maybe you want the Win32 page. There are some links to it in
-On [20030908 20:52], Rod Taylor ([EMAIL PROTECTED]) wrote:
>This could be rather time consuming to actually write but having the
>ability to change foreign key on update / on delete modes without
>rechecking all of the data would be very useful.
I was more interested in this feature
On Monday 08 September 2003 17:14, Andreas Pflug wrote:
> Richard Huxton wrote:
> >Actually, a simple trace ability would be a huge step forward. It'd save
> > me dotting RAISE statements around my functions while I write them.
>
> Sounds bloody familiar... :-(
>
> > Even the ability to add DEBUG s
On Mon, 2003-09-08 at 14:32, Jeroen Ruigrok/asmodai wrote:
> Hi people,
>
> can someone add:
>
> Add an ALTER TABLE MODIFY CONSTRAINT
>
> item to the todo list? I am even willing to pick this one up in a
> while, after I finish some other outstanding tasks.
This could be rather time consuming
> -Original Message-
> From: luke [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 08, 2003 9:16 AM
> To: Hackers
> Subject: [HACKERS] pgsql vc++|win32
>
>
> Hi guys, I'm planning with some friends to develop a
> port of pgsql, to native win32 environment using vc++;
>
> We read abou
Hi people,
can someone add:
Add an ALTER TABLE MODIFY CONSTRAINT
item to the todo list? I am even willing to pick this one up in a
while, after I finish some other outstanding tasks.
--
Jeroen Ruigrok van der Werven / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625
On Mon, 2003-09-08 at 11:09, Gaetano Mendola wrote:
> "Tom Lane" <[EMAIL PROTECTED]> wrote:
> > I see no value at all in an assert. The code will dump core just fine
> > with or without an assert ...
>
> Right but an assert can display information about the file and line number
> without debug t
Tom Lane wrote:
Doug McNaught <[EMAIL PROTECTED]> writes:
I agree with another poster that deprecation in 7.4 and removal in
7.5 might make sense.
How would we "deprecate" it exactly? Throw a NOTICE?
Release notes, I guess. A NOTICE would be fine as long as it didn't
result in a floo
On Mon, Sep 08, 2003 at 10:17:46AM -0700, Jenny - wrote:
> >TupleTables are just temporary data structures to hold transiently
> >created tuples during execution of a query. There's usually one for
> >each plan node.
> whats a 'plan node'?
Have you tried reading the documentation, source code a
-On [20030908 18:52], Bruce Momjian ([EMAIL PROTECTED]) wrote:
>So you don't have all the *_r functions, and your non-*_r functions
>aren't thread-safe. Should we disable theading on FreeBSD? Seems so.
Exactly. Most other threading works though. :)
--
Jeroen Ruigrok van der W
TupleTables are just temporary data structures to hold transiently
created tuples during execution of a query. There's usually one for
each plan node.
whats a 'plan node'?
From: Tom Lane <[EMAIL PROTECTED]>
To: "Jenny -" <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [HACKERS] row level
> Date: Mon, 08 Sep 2003 09:57:30 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
>
> "Gaetano Mendola" <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> wrote:
> >> This seems inappropriate to me. Are you going to suggest that every
> >> routine that takes a pointer parameter needs to ex
--On Monday, September 08, 2003 12:50:18 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Jeroen Ruigrok/asmodai wrote:
-On [20030908 06:32], Bruce Momjian ([EMAIL PROTECTED]) wrote:
>> Your gethostbyname() is _not_ thread-safe
>> Your getpwuid() is _not_ thread-safe
>>
On Monday 08 September 2003 18:15, luke wrote:
> Hi guys, I'm planning with some friends to develop a
> port of pgsql, to native win32 environment using vc++;
>
> We read about MingW choice of official dev team, and we comprise
> their worries but we think that best results could be obtained
> usin
Tom Lane wrote:
Doug McNaught <[EMAIL PROTECTED]> writes:
I agree with another poster that deprecation in 7.4 and removal in
7.5 might make sense.
How would we "deprecate" it exactly? Throw a NOTICE?
Good question. A NOTICE just might be ignored, breaking everything
"surprisingly" in 7.
Tom Lane <[EMAIL PROTECTED]> writes:
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > I agree with another poster that deprecation in 7.4 and removal in
> > 7.5 might make sense.
>
> How would we "deprecate" it exactly? Throw a NOTICE?
I was thinking of just a mention in the release notes that w
Jeroen Ruigrok/asmodai wrote:
> -On [20030908 06:32], Bruce Momjian ([EMAIL PROTECTED]) wrote:
> >> Your gethostbyname() is _not_ thread-safe
> >> Your getpwuid() is _not_ thread-safe
> >> Your functions are _not_ all thread-safe
> >
> >Interesting
"Jenny -" <[EMAIL PROTECTED]> writes:
> I found out that TupleTable stores per-tuple information(it stores
> HeapTupleData) and that also there are multiple TupleTables in the db at a
> time.Based on what are diffrent TupleTables created?
TupleTables are just temporary data structures to hold tr
Doug McNaught <[EMAIL PROTECTED]> writes:
> I agree with another poster that deprecation in 7.4 and removal in
> 7.5 might make sense.
How would we "deprecate" it exactly? Throw a NOTICE?
regards, tom lane
---(end of broadcast)
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
> >
> >2. Throw an error if the expression doesn't return boolean.
> >
> I'd opt for 2.
> It's quite common that newer compilers will detect more bogus coding
> than older ones. There might be existing functions that break from
> this
Tom Lane wrote:
Here are some possible responses, roughly in order of difficulty
to implement:
1. Leave well enough alone (and perhaps document the behavior).
2. Throw an error if the expression doesn't return boolean.
I'd opt for 2.
It's quite common that newer compilers will detect more bogus
HI,
I found out that TupleTable stores per-tuple information(it stores
HeapTupleData) and that also there are multiple TupleTables in the db at a
time.Based on what are diffrent TupleTables created?
thank you
Jenny
From: Larry Douzie <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
CC: [EMA
Hi guys, I'm planning with some friends to develop a
port of pgsql, to native win32 environment using vc++;
We read about MingW choice of official dev team, and we comprise
their worries but we think that best results could be obtained
using some really native win32 libraries (for better or for wo
Richard Huxton wrote:
Actually, a simple trace ability would be a huge step forward. It'd save me
dotting RAISE statements around my functions while I write them.
Sounds bloody familiar... :-(
Even the ability to add DEBUG statements that checked some global flag before firing
would be very us
Tom Lane wrote:
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
the
On Monday 08 September 2003 15:14, Andreas Pflug wrote:
>
> Looking at the code, I think that a validator could be added quite soon.
> The PLpgSQL_execstate struct could be extended by a validation_active
> bool flag, which changes the behaviour of all exec_stmt_XXX routines.
> The validator primar
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression. It
doesn't take any measures to ensure this is the case or convert
the value if it's no
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Gaetano Mendola" <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> wrote:
> >> This seems inappropriate to me. Are you going to suggest that every
> >> routine that takes a pointer parameter needs to explicitly test for
> >> null?
>
> > Of cou
"Conrad Vermeulen" <[EMAIL PROTECTED]> writes:
> Possibly my quick hack may not work if the parser
> predetermines the type as the functionality required would only really be
> able to determine the type at time of execution.
The problem is that the first time through, the execution plan for the
The current implementation of plpgsql lacks some details that makes
programming really hard: there's no language validator to check the code
when creating the function, and there's support to debug the code.
Before I start hacking on this, I'd like to share my thoughts.
Looking at the code, I t
"Gaetano Mendola" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> This seems inappropriate to me. Are you going to suggest that every
>> routine that takes a pointer parameter needs to explicitly test for
>> null?
> Of course I'm not suggesting this, what I'm suggesting is
On Mon, Sep 08, 2003 at 19:13:47 +0530,
Shridhar Daithankar <[EMAIL PROTECTED]> wrote:
> On 8 Sep 2003 at 8:42, Bruno Wolff III wrote:
>
> If that was hash index, Tom suggested to bump version number of the indexes in
> later versions and throw an error and ask user to reindex that particular
On 8 Sep 2003 at 8:42, Bruno Wolff III wrote:
> On Mon, Sep 08, 2003 at 15:25:12 +0200,
> Andreas Joseph Krogh <[EMAIL PROTECTED]> wrote:
> >
> > That's what I thought. I remember from the 7.3 beta-period that it broke
> > between beta2 and beta3 or so and am wondering if the developers are aw
On Mon, Sep 08, 2003 at 15:25:12 +0200,
Andreas Joseph Krogh <[EMAIL PROTECTED]> wrote:
>
> That's what I thought. I remember from the 7.3 beta-period that it broke
> between beta2 and beta3 or so and am wondering if the developers are aware of
> any known issues which might require an initdb
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 08 September 2003 15:27, Bruno Wolff III wrote:
> On Mon, Sep 08, 2003 at 14:45:41 +0200,
>
> Andreas Joseph Krogh <[EMAIL PROTECTED]> wrote:
> > Will there be any more on-disk format changes before 7.4 goes final which
> > will require a d
On Mon, Sep 08, 2003 at 14:45:41 +0200,
Andreas Joseph Krogh <[EMAIL PROTECTED]> wrote:
>
> Will there be any more on-disk format changes before 7.4 goes final which will
> require a dump-restore, or is that impossible to say?
While it is impossible to say with 100% certainly, the developers g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Will there be any more on-disk format changes before 7.4 goes final which will
require a dump-restore, or is that impossible to say?
- --
Andreas Joseph Krogh <[EMAIL PROTECTED]>
Managing Director, Senior Software Developer
OfficeNet AS
- - Th
On Mon, 8 Sep 2003 11:31:05 +0200, "Zeugswetter Andreas SB SD"
<[EMAIL PROTECTED]> wrote:
>> As Tom mentioned, we might not want to keep the tid's in order after the
>> index is created because he wants the most recent tid's first, so the
>> expired ones migrate to the end.
>
>But on average this a
"Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Mendola Gaetano" <[EMAIL PROTECTED]> writes:
> > A test for null string is missing here:
>
> > MemoryContextStrdup(MemoryContext context, const char *string)
> > {
> > char *nstr;
> > -
> > - if ( !string )
> > - {
> > - elog(ERROR, "MemoryContextStrdup cal
> > I don't think so, because the patch does nothing to keep the sort
> > order once the index is initially created.
>
> As Tom mentioned, we might not want to keep the tid's in order after the
> index is created because he wants the most recent tid's first, so the
> expired ones migrate to the e
As part of attempting to gain an understanding of how Postgres works, I
wanted to see if I could display a summary of what relations were using
pages in the cache.
Having done that, I was all set to trash the code when I wondered if it
might be useful in its own right...
Here is a sample of th
Hi,
I had a problem where I needed to indirectly dereference a field from a
record.
To illustrate:
CREATE FUNCTION test2() returns bool as '
DECLARE
myrec record;
fld text;
BEGIN
select ''hello'' as a, ''world'' as b into myrec;
fld = ''a''; -- the fieldname fro
72 matches
Mail list logo
