> -Original Message-
> From: ow [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 17, 2003 10:39 PM
> To: Christopher Kings-Lynne; Greg Stark
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
>
>
>
> --- Christopher Kings-Lynne <[EMAIL PROTECTED]> wro
Matthew T. O'Connor wrote:
Christopher Kings-Lynne wrote:
Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on
dozens of
OSes already. What's so exciting about one more? Even if it is a
pathologically hard OS to port to. Just because it was hard doesn't
mean it's
useful.
I don
--- Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>
> I don't call porting Postgres to run well on something like 40% of the
> world's servers (or whatever it is) "just another port".
Statistics is a tricky thing. IMHO, there are plenty of things that are much
more important than win32 por
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 17, 2003 10:34 PM
> To: Dann Corbit
> Cc: Matthew T. O'Connor; Christopher Kings-Lynne; Greg Stark;
> PostgreSQL Development
> Subject: RE: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
>
>
Dann Corbit writes:
> > At the risk of stating the obvious: Cygwin is your friend in
> > exactly this case.
>
> Yes, but how friendly is it?
What are you asking here? Is it easy to install and use? Yes.
> Cygwin requires a license for commercial use.
No, it does not.
--
Peter Eisentraut [
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 17, 2003 10:04 PM
> To: Matthew T. O'Connor
> Cc: Christopher Kings-Lynne; Greg Stark; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
>
>
> Matthew T. O'Connor
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > I don't call porting Postgres to run well on something like 40% of the
> > world's servers (or whatever it is) "just another port".
> >
> > It could conveivably double Postgres's target audience, could attract heaps
> > of new users, new devel
Matthew T. O'Connor writes:
> Absolutely! In addition, even if you don't consider win32 a platform to
> run production databases on, the win32 port will help developers who
> work from windows boxes, which is the certainly the most widely used
> desktop environment.
At the risk of stating the ob
On Tue, 18 Nov 2003, Neil Conway wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Tue, 18 Nov 2003, Peter Eisentraut wrote:
> >
> >> 0. As you say, make it known to the public. Have people test their
> >>in-development applications using a beta.
> >
> > and how do you propose we
Christopher Kings-Lynne wrote:
Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on
dozens of
OSes already. What's so exciting about one more? Even if it is a
pathologically hard OS to port to. Just because it was hard doesn't
mean it's
useful.
I don't call porting Postgres to run
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Tue, 18 Nov 2003, Peter Eisentraut wrote:
>
>> 0. As you say, make it known to the public. Have people test their
>>in-development applications using a beta.
>
> and how do you propose we do that? I think this is the hard part
(1) Make the
Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens of
OSes already. What's so exciting about one more? Even if it is a
pathologically hard OS to port to. Just because it was hard doesn't mean it's
useful.
I don't call porting Postgres to run well on something like 40% of the
Mike Mascari <[EMAIL PROTECTED]> writes:
> 1) PITR
> 2) Distributed Tx
> 3) Replication
> 4) Nested Tx
> 5) PL/SQL Exception Handling
Of these PITR seems *by far* the most important. It makes the difference
between an enterprise-class database capable of running 24x7 with disaster
recovery plans
Since I can't just go in an remove all the v's from the directory names in
the ftp site, without breaking any links to the ftp servers, I just
created a new directory that contains the 'non-v' names, with symlink's to
the v'd directories ...
ftp://ftp.postgresql.org/pub/src/[167].*
vs
ftp://ftp
On Mon, 17 Nov 2003, Larry Rosenman wrote:
>
> I try to test stuff fairly frequently, and this time I didn't know when,
> exactly, SCO would make the release of the updated compiler.
And there was no way you could predict that your contact there would take
off on holidays either :(
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
> 0. As you say, make it known to the public. Have people test their
>in-development applications using a beta.
and how do you propose we do that? I think this is the hard part ...
other then the first beta, I post a note out to -announce and -ge
--On Tuesday, November 18, 2003 04:43:12 +0100 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Neil Conway writes:
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta pr
eg. Someone who just knows how to use postgres could test my upcoming
COMMENT ON patch. (It's best if I myself do not test it) Someone with
more skill with a debugger can be asked to test unique hash indexes by
playing with concurrency, etc.
I forgot to mention that people who just have large,
On Mon, 17 Nov 2003, Neil Conway wrote:
> That said, I'm not really sure how we can make better use of the beta
> period. One obvious improvement would be making the beta announcements
> more visible: the obscurity of the beta process on www.postgresql.org
> for 7.4 was pretty ridiculous. Does an
Neil Conway writes:
> That said, I'm not really sure how we can make better use of the beta
> period. One obvious improvement would be making the beta announcements
> more visible: the obscurity of the beta process on www.postgresql.org
> for 7.4 was pretty ridiculous. Does anyone else have a sugg
That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta process on www.postgresql.org
for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
what we can do to p
Matthew T. O'Connor wrote:
> I agree with Peter's other comment, that the longer the development
> cycle, the longer the beta / bug shakeout period, perhaps a shorter dev
> cycle would yield a shorter beta period, but perhaps it would also
> result in a less solid release.
Perhaps. Perhaps not
Neil Conway wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > First, if you develop something today, the first time users would
> > realistically get a hand at it would be January 2005. Do you want
> > that? Don't you want people to use your code?
>
> Sure :-) But I don't mind a long rel
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
> Christopher Kings-Lynne writes:
>
> > BTW, one main consideration is that all the postgres admin apps will now
> > need to support ORDER BY attlognum for 7.5+.
>
> But that is only really important if they've also used the ALTER TABLE
> RESHUFFLE COL
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> So 7.4 took about 4.5 months to get from feature freeze to release.
> I think feature freeze is the important date that developers of new
> features need to concern themselves with.
Rather than the length of the release cycle, I think it's the le
BTW, one main consideration is that all the postgres admin apps will now
need to support ORDER BY attlognum for 7.5+.
But that is only really important if they've also used the ALTER TABLE
RESHUFFLE COLUMNS feature. So if they make one alteration for 7.5, they
need to do another. That seems fai
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
> Marc G. Fournier writes:
>
> > Right now, I believe we are looking at an April 1st beta, and a May 1st
> > related ... those are, as always, *tentative* dates that will become more
> > fine-tuned as those dates become nearer ...
>
> OK, here start the
Christopher Kings-Lynne writes:
> BTW, one main consideration is that all the postgres admin apps will now
> need to support ORDER BY attlognum for 7.5+.
But that is only really important if they've also used the ALTER TABLE
RESHUFFLE COLUMNS feature. So if they make one alteration for 7.5, they
On Mon, 2003-11-17 at 20:24, Christopher Kings-Lynne wrote:
> > Right -- AFAICS, the only change in COPY compatibility would be if you
> > COPY TO'd a table and then changed the logical column order in some
> > fashion, you would no longer be able to restore the dump (unless you
> > specified a col
Peter Eisentraut wrote:
Marc G. Fournier writes:
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
OK, here start the problems. Development already s
Josh Berkus wrote:
> > Also note that most major number
> > changes in the past weren't because the features were cool, but because
> > the project has moved to a new phase. I don't see any such move
> > happening.
>
> Now that is interesting. I missed that. Can you explain how that worked
>
Manfred Spraul wrote:
> Hi,
>
> I've searched through libpq and looked for global or static variables as
> indicators of non-threadsafe code. I found:
> - Win32 and BeOS: there is a global "ioctlsocket_ret variable, but it
> seems to be a dummy variable that is always discarded.
Right, and it i
Marc G. Fournier writes:
> Right now, I believe we are looking at an April 1st beta, and a May 1st
> related ... those are, as always, *tentative* dates that will become more
> fine-tuned as those dates become nearer ...
OK, here start the problems. Development already started, so April 1st is
a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> First, if you develop something today, the first time users would
> realistically get a hand at it would be January 2005. Do you want
> that? Don't you want people to use your code?
Sure :-) But I don't mind a long release cycle if it is better for
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Hello,
>
>Personally I am for long release cycles, at least for major releases.
> In fact
> as of 7.4 I think there should possibly be a slow down in releases with more
> incremental releases (minor releases) throughout the year.
That would pr
Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...
April 1st, or 4 mos from last release, tends to be what we aim for with
all releases ... as everyone knows, w
On Tue, 18 Nov 2003, Christopher Kings-Lynne wrote:
> > Everyone on -hackers should have been aware of it, as its always
> > discussed at the end of the previous release cycle ... and I don't think
> > we've hit a release cycle yet that has actually stayed in the 4 month
> > period :( Someone is
--On Tuesday, November 18, 2003 09:59:32 +0800 Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
Wait for confirmation from at least one other developer perhaps, buy you
can try this:
1. Set attisdropped to false for the attribute
2. Set the atttypid back to whatever the oid of the type of th
Hello,
Personally I am for long release cycles, at least for major releases.
In fact
as of 7.4 I think there should possibly be a slow down in releases with more
incremental releases (minor releases) throughout the year.
People are running their companies and lives off of PostgreSQL, they
s
--On Monday, November 17, 2003 19:36:08 -0600 Larry Rosenman
<[EMAIL PROTECTED]> wrote:
I screwed up, and dropped a column when I shouldn't have.
I have *not* vacuumed this DB yet.
Is there any catalog mucking I can do to bring it back?
Actually, I got lucky. pg_catalog.pg_attribute is what
Wait for confirmation from at least one other developer perhaps, buy you
can try this:
1. Set attisdropped to false for the attribute
2. Set the atttypid back to whatever the oid of the type of that column
is/was (Compare to an undropped similar column)
3. Use ALTER TABLE/SET NOT NULL on the
Neil Conway wrote:
> I'd like to add a new column to pg_attribute that specifies the
> attribute's "logical position" within its relation. The idea here is
> to separate the logical order of the columns in a relation from the
> on-disk storage of the relation's tuples. This allows us to easily &
>
Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always 'just sitting on something that is almost
done' at the end th
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a
Neil Conway wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I don't think you can speak of "bloat" for pg_attribute. But you
> > can speak of a problem when you want to do the old col = col + 1 in
> > the presence of a unique index.
>
> I'm sorry, but I'm not sure what either of these c
I screwed up, and dropped a column when I shouldn't have.
I have *not* vacuumed this DB yet.
Is there any catalog mucking I can do to bring it back?
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 190
Neil Conway writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The time from release 7.3 to release 7.4 was 355 days, an all-time
> > high. We really need to shorten that.
>
> Why is that?
First, if you develop something today, the first time users would
realistically get a hand at it wo
Right -- AFAICS, the only change in COPY compatibility would be if you
COPY TO'd a table and then changed the logical column order in some
fashion, you would no longer be able to restore the dump (unless you
specified a column list for the COPY FROM -- which, btw, pg_dump
does). I don't think it wi
Marc G. Fournier writes:
> Just did a quick search on archives, and the original plan was for a
> release in mid-2003, which means the beta would have been *at least* a
> month before that, so beta starting around May:
>
> http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php
That was
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The time from release 7.3 to release 7.4 was 355 days, an all-time
> high. We really need to shorten that.
Why is that?
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please
Just did a quick search on archives, and the original plan was for a
release in mid-2003, which means the beta would have been *at least* a
month before that, so beta starting around May:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php
On Mon, 17 Nov 2003, Marc G. Fournier wrot
Joshua D. Drake wrote:
> Hello,
>
> If Win32 actually makes it into 7.5 then yes I believe 8.0 would be
> appropriate.
It might be interesting to track Oracle's version number viz. its
feature list. IOW, a PostgreSQL 8.0 database would be feature
equivalent to an Oracle 8.0 database. That woul
Tommi Maekitalo wrote:
> Hi,
>
> in doc/man1/psql.1 there is a line:
> "Welcome to psql 7.4beta5, the PostgreSQL interactive terminal."
Yea, sorry. It pulls the version number from the time those man pages
were built. Not sure how we could have prevented it.
--
Bruce Momjian
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
> Marc G. Fournier writes:
>
> > That is the usual goal *nod* Same goal we try for each release, and never
> > quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
> > always do :)
>
> I don't see how we could have tried for a 4-mon
Hannu Krosing wrote:
> Bruce Momjian kirjutas E, 17.11.2003 kell 02:31:
>
> > Defining now() as the first call seems pretty arbitrary to me. I can't
> > think of any time-based interface that has that API. And what if a
> > trigger called now() in an earlier query and you didn't even know about
Marc G. Fournier writes:
> That is the usual goal *nod* Same goal we try for each release, and never
> quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
> always do :)
I don't see how we could have tried for a 4-month development period and
ended up with an 8-month period.
On Mon, 17 Nov 2003, Josh Berkus wrote:
> Given all that, don't people think it's time to jump to 8.0? Seems like
> even 7.4 is hardly recognizable as the same database as 7.0.
Discussion like this tends to be more for just before beta, once we have
an idea what actually made it in :) You be pu
On Tue, 18 Nov 2003, Peter Eisentraut wrote:
> The time from release 7.3 to release 7.4 was 355 days, an all-time high.
> We really need to shorten that. We already have a number of significant
> improvements in 7.5 now, and several good ones coming up in the next few
> weeks. We cannot let peop
Shridhar Daithankar wrote:
> On Friday 14 November 2003 22:10, Jan Wieck wrote:
> > Shridhar Daithankar wrote:
> > > On Friday 14 November 2003 03:05, Jan Wieck wrote:
> > >> For sure the sync() needs to be replaced by the discussed fsync() of
> > >> recently written files. And I think the algorith
> As has been said before, many people think that a Windows port is the
> least interesting feature ever to happen to PostgreSQL, so you're going to
Yes but these are people running Unix/Linux/BSD not Windows ;)
> have to come up with better reasons. Also note that most major number
> changes i
Hello,
If Win32 actually makes it into 7.5 then yes I believe 8.0 would be
appropriate.
Sincerely,
Joshua D. Drake
On Mon, 17 Nov 2003, Josh Berkus wrote:
> Folks,
>
> Of course, while I was editing press releases at 2am, I started thinking about
> our next version. It seems certain tha
The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a
Peter,
> As has been said before, many people think that a Windows port is the
> least interesting feature ever to happen to PostgreSQL, so you're going to
> have to come up with better reasons.
Yeah, I'm more interested in ARC and replication ... and the SQL
standardization that just went into
Josh Berkus writes:
> Given all that, don't people think it's time to jump to 8.0?
As has been said before, many people think that a Windows port is the
least interesting feature ever to happen to PostgreSQL, so you're going to
have to come up with better reasons. Also note that most major numbe
Josh Berkus <[EMAIL PROTECTED]> writes:
> It seems certain that the next release, in 6-9 months, will have at
> a minimum the Windows port and ARC, if not Slony-I as well.
>
> Given all that, don't people think it's time to jump to 8.0?
It seems a little premature to speculate on what features may
Folks,
Of course, while I was editing press releases at 2am, I started thinking about
our next version. It seems certain that the next release, in 6-9 months,
will have at a minimum the Windows port and ARC, if not Slony-I as well.
Given all that, don't people think it's time to jump to 8.0?
On Sun, Nov 02, 2003 at 07:25:38AM -0500, Rod Taylor wrote:
> On Sat, 2003-11-01 at 20:58, Mark Wong wrote:
> > I don't remember making a conscious decision between the number and integer
> > database type. Is that a significant oversight on my part?
>
> Numerics do exact math with support for ar
Yesterday I was a bit worried... I switched to SuSE just 2 weeks ago...
my newly installed databse server was waitinI thought that I would have
to wait so much to have RPMs for SuSE and today I see v7.4 compiled for
many flavors of SuSE, even for X86-64. Wow :)
Thanks :)
--
Daniele Orlandi
--
Hi,
I've searched through libpq and looked for global or static variables as
indicators of non-threadsafe code. I found:
- Win32 and BeOS: there is a global "ioctlsocket_ret variable, but it
seems to be a dummy variable that is always discarded.
- pg_krb4_init(): Are the kerberos libraries threa
http://www.coyotegulch.com/acovea/index.html
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Er, that's a per-server limit, not a per-database limit (which is what
he asked for), isn't it?
cheers
andrew
Dann Corbit wrote:
It's a command line option for the server.
http://developer.postgresql.org/docs/postgres/app-postmaster.html
-Original Message-
From: [EMAIL PROTECTED]
Oops. Never mind. I did not read your message carefully.
> -Original Message-
> From: Dann Corbit
> Sent: Monday, November 17, 2003 11:51 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Connexions question
>
>
> It's a command line option for the server.
>
It's a command line option for the server.
http://developer.postgresql.org/docs/postgres/app-postmaster.html
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 17, 2003 11:21 AM
> To: pgsql-hackers list
> Subject: [HACKERS] Connexions questi
The PostgreSQL group has recently had a patch submitted with a snippet
of code from FreeBSDs src/bin/mkdir/mkdir.c.
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27
Is this intentionally under the 4 clause license or does the copyright
from the website (2 clause) applied
Hi all,
I don't think it's a FAQ, Is it possible to limit then number of
simultaneous connexions one can make to a particular databse.
E.G: I have 128 connexions max of witch I wan't to restrict at most 60 to
database x, leaving in the worst case 68 for all others...
Am I clear?
--
Olivier PRE
Jon Jensen <[EMAIL PROTECTED]> writes:
> You're just saying it'd break old dumps, right? I'd assume COPY FROM
> would use attpos ordering when writing out columns, or that every
> user-visible interaction with the table pretends the columns are in
> attpos order. So dumps would break no more or les
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't think you can speak of "bloat" for pg_attribute. But you
> can speak of a problem when you want to do the old col = col + 1 in
> the presence of a unique index.
I'm sorry, but I'm not sure what either of these comments mean -- can
you elabora
On Mon, 17 Nov 2003, Neil Conway wrote:
> I'd like to add a new column to pg_attribute that specifies the
> attribute's "logical position" within its relation. The idea here is
> to separate the logical order of the columns in a relation from the
> on-disk storage of the relation's tuples. This al
Neil Conway writes:
> (b) Using the above scheme that attnum == attpos initially, there
> won't be any gaps in the sequence of attpos values. That means
> that if, for example, we want to move the column in position 50
> to position 1, we'll need to change the position's of all
Sorry, I did find the offending driver in the end... And it is running
happily now.
Sorry for the noise
Adam
> Hi,
>
> I suspect this a problem local to my machine, but I cannot compile with the
> --with-java option... It fails like so
>
> driver:
>[copy] Copying 1 file to
> /usr/local/
I'd like to add a new column to pg_attribute that specifies the
attribute's "logical position" within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily &
quickly change column order,
I'd like to add a new column to pg_attribute that specifies the
attribute's "logical position" within its relation. The idea here is
to separate the logical order of the columns in a relation from the
on-disk storage of the relation's tuples. This allows us to easily &
quickly change column order,
Hi,
I suspect this a problem local to my machine, but I cannot compile with the
--with-java option... It fails like so
driver:
[copy] Copying 1 file to
/usr/local/install/postgresql-7.4/src/interfaces/jdbc/org/postgresql
[echo] Configured build for the JDBC3 edition driver with SSL
co
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Where am I wrong?
>
> I don't think any of this is relevant. There are a certain number of
> blocks we have to get down to disk before we can declare a transaction
> committed, and there are a certain number that we have to get down
-- value-independent transition function
CREATE AGGREGATE newcnt (
sfunc = int4inc, basetype = 'any', stype = int4,
initcond = '0'
);
COMMENT ON AGGREGATE newcnt (any) IS 'an any agg comment';
ERROR: syntax error at or near "any" at character 30
COMMENT ON AGGREGATE newcnt (any) IS NULL;
ERR
> 1. Open WAL files with O_SYNC|O_DIRECT or O_SYNC(Not sure if
Without grouping WAL writes that does not fly. Iff however such grouping
is implemented that should deliver optimal performance. I don't think flushing
WAL to the OS early (before a tx commits) is necessary, since writing 8k or 256
Bruce Momjian kirjutas E, 17.11.2003 kell 02:31:
> Defining now() as the first call seems pretty arbitrary to me. I can't
> think of any time-based interface that has that API. And what if a
> trigger called now() in an earlier query and you didn't even know about
> it.
That would be OK. The wh
Tom Lane kirjutas E, 17.11.2003 kell 02:08:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Hmmm... I agree this behavior isn't ideal, although I can see the case
> > for viewing this as a mistake by the application developer: they are
> > assuming that they know exactly when transactions begin, whic
Hi,
in doc/man1/psql.1 there is a line:
"Welcome to psql 7.4beta5, the PostgreSQL interactive terminal."
Tommi
Am Montag, 17. November 2003 02:23 schrieb Marc G. Fournier:
> 'k, I just moved the release into the /pub/source/v7.4 directory from the
> v7.4beta one ... RC2 is still in place, so tha
On Friday 14 November 2003 22:10, Jan Wieck wrote:
> Shridhar Daithankar wrote:
> > On Friday 14 November 2003 03:05, Jan Wieck wrote:
> >> For sure the sync() needs to be replaced by the discussed fsync() of
> >> recently written files. And I think the algorithm how much and how often
> >> to flus
On Sun, 17 Nov 2003, Greg Stark wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
>
> > What does BEGIN actually do now, from a user's perspective?
>
> I think you're thinking about this all wrong. BEGIN doesn't "do" anything.
> It's not a procedural statement, it's a declaration. It declares that
91 matches
Mail list logo
