bigapple wrote:
> hi,
> When I check out the pgsql from cvs and I complile it, an error occured .
>
> dir: pgsql/src/interfaces/ecpg/preproc
> bison -y -d preproc.y
> erro information:
> preproc.y:5559: fatal error: maximum table size (32767) exceeded.
>
You need at least version 1.5 of biso
On Mon, 2002-12-09 at 01:58, bigapple wrote:
> When I check out the pgsql from cvs and I complile it, an error occured .
>
> dir: pgsql/src/interfaces/ecpg/preproc
> bison -y -d preproc.y
> erro information:
> preproc.y:5559: fatal error: maximum table size (32767) exceeded.
You need to use B
hi,
When I check out the pgsql from cvs and I complile it, an error occured .
dir: pgsql/src/interfaces/ecpg/preproc
bison -y -d preproc.y
erro information:
preproc.y:5559: fatal error: maximum table size (32767) exceeded.
However, I used the source from the ftp, find preproc.c in there. gma
Vince, Peter:
I can definitely understand someone not wanting to *participate* in
marketing/advocacy of PostgreSQL. However, your being opposed to
promoting PostgreSQL as an organized activity *at all* baffles me. How
can you be against promoting PostgreSQL? Don't you want poeple to use
your c
On Sunday 08 December 2002 11:32 pm, Vince Vielhaber wrote:
> Exactly, and pgsql-www is the wrong goddam list! I've told you over
> and over again. pgsql-www is the list that the group leaders use to
> collaborate.
And a fine job of collaboration you're doing *obviously*
> Over and over again
On Sun, 8 Dec 2002, Robert Treat wrote:
> On Saturday 07 December 2002 11:10 pm, Vince Vielhaber wrote:
> > On 5 Dec 2002, Robert Treat wrote:
> > > On Thu, 2002-12-05 at 03:28, Dave Page wrote:
> > > > www is a closed group consisting of a few of us who actually do the
> > > > work on the sites.
On Saturday 07 December 2002 11:10 pm, Vince Vielhaber wrote:
> On 5 Dec 2002, Robert Treat wrote:
> > On Thu, 2002-12-05 at 03:28, Dave Page wrote:
> > > www is a closed group consisting of a few of us who actually do the
> > > work on the sites.
> >
> > This is one of the primary reasons the site
On Sunday 08 December 2002 06:14 pm, Vince Vielhaber wrote:
> On 8 Dec 2002, Oliver Elphick wrote:
> > On Sun, 2002-12-08 at 22:27, Vince Vielhaber wrote:
> > > On 8 Dec 2002, Oliver Elphick wrote:
> > > > If something is familiar, it feels safe. We need to make PostgreSQL
> > > > familiar. That'
Tom Lane wrote:
This crystallizes something that has been bothering me for awhile: the
table function syntax is severely hobbled (not to say crippled :-() by
the fact that the function arguments have to be constants. You really
don't want to have to invent intermediate functions every time you wa
Oliver Elphick wrote:
> If we want people to use PostgreSQL in preference to anything else, we
> have to make it known. That is marketing. If we believe we have a good
> product we need to say so and say why and how it's better, cheaper and
> purer than anything else. If there's no good marketi
On Mon, 9 Dec 2002, Justin Clift wrote:
> Vince Vielhaber wrote:
> >
> > That's what I thought. You have no argument so your just typing.
>
> Hi Vince,
>
> Was more hoping you'd care to share your basis for stating Robert's
> employers clients wanted a "commercial database", after he mentioned
>
Vince Vielhaber wrote:
>
That's what I thought. You have no argument so your just typing.
Hi Vince,
Was more hoping you'd care to share your basis for stating Robert's
employers clients wanted a "commercial database", after he mentioned
specifically DB2 and Oracle. Knowing one of the obviou
On 8 Dec 2002, Oliver Elphick wrote:
> On Sun, 2002-12-08 at 22:27, Vince Vielhaber wrote:
> > On 8 Dec 2002, Oliver Elphick wrote:
>
> > > If something is familiar, it feels safe. We need to make PostgreSQL
> > > familiar. That's why we need marketing.
> >
> > Then why wasn't mysql in the list?
On Sun, 2002-12-08 at 22:27, Vince Vielhaber wrote:
> On 8 Dec 2002, Oliver Elphick wrote:
> > If something is familiar, it feels safe. We need to make PostgreSQL
> > familiar. That's why we need marketing.
>
> Then why wasn't mysql in the list? It's familiar.
To PHBs?
MySQL doesn't have any
On Sun, Dec 08, 2002 at 05:28:22PM -0500, Tom Lane wrote:
>
> Well, you could dig through backend/executor/node*.c and see which of
> the node types pay attention to es_direction. To a first approximation
> it looks like these do:
I'll be honest with you: I don't know much about the internals a
On Mon, 9 Dec 2002, Justin Clift wrote:
> Vince Vielhaber wrote:
> > On Mon, 9 Dec 2002, Justin Clift wrote:
> >
> >
> >>Vince Vielhaber wrote:
> >>
> >>>Because of this taken from the above quoted text:
> >>>
> >>>"they were under constant assault from their clients to use oracle or db2"
> >>>
>
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Now if I understood a bit more of what's going on here, at least I could
> document it...
Well, you could dig through backend/executor/node*.c and see which of
the node types pay attention to es_direction. To a first approximation
it looks like
On 8 Dec 2002, Oliver Elphick wrote:
> On Sun, 2002-12-08 at 20:52, Vince Vielhaber wrote:
> > > Why do you say that?
> >
> > Because of this taken from the above quoted text:
> >
> > "they were under constant assault from their clients to use oracle or db2"
> >
> > Last I looked neither Oracle or
Vince Vielhaber wrote:
On Mon, 9 Dec 2002, Justin Clift wrote:
Vince Vielhaber wrote:
Because of this taken from the above quoted text:
"they were under constant assault from their clients to use oracle or db2"
Last I looked neither Oracle or DB2 were open source, but they both just
happen
On Sun, Dec 08, 2002 at 05:09:09PM -0500, Tom Lane wrote:
>
> > Is any of this described in the docs somewhere?
>
> Fraid not.
Damn & blast. I was rather counting on cursors that could back up for
my nifty CachedResult class (which acts more or less like a normal result
set but transparently f
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Ah, I didn't know that. I guess the plan for "select * from pg_tables"
> must have changed in 7.3 then.
[looks...] Yeah, there's a join to pg_namespace in there now.
> Is any of this described in the docs somewhere?
Fraid not.
On Mon, 9 Dec 2002, Justin Clift wrote:
> Vince Vielhaber wrote:
> > Because of this taken from the above quoted text:
> >
> > "they were under constant assault from their clients to use oracle or db2"
> >
> > Last I looked neither Oracle or DB2 were open source, but they both just
> > happen to b
Joe Conway <[EMAIL PROTECTED]> writes:
> [ much snipped ]
> The first function borrows from an idea Nigel Andrews had -- i.e. expand an
> array into rows (and possibly columns). It currently works like this:
> -- 1D array
> test=# select * from array_values('{101,102,103,104}'::int[]) as (a int,
On Sun, 2002-12-08 at 20:52, Vince Vielhaber wrote:
> > Why do you say that?
>
> Because of this taken from the above quoted text:
>
> "they were under constant assault from their clients to use oracle or db2"
>
> Last I looked neither Oracle or DB2 were open source, but they both just
> happen
On Sun, Dec 08, 2002 at 04:28:38PM -0500, Tom Lane wrote:
>
> I believe it is true though that backing up a cursor only works for
> certain plan types (seqscan, indexscan, sort, maybe a couple others).
> That has always been true --- 7.3 is no better nor worse than prior
> releases.
Ah, I didn't
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Looking at my problem with changed cursor behaviour in 7.3 again, I
> noticed something interesting: a cursor in 7.3 apparently does not let
> you scroll back to its first row at all!
Oh?
regression=# begin;
BEGIN
regression=# declare c cursor
Vince Vielhaber wrote:
Because of this taken from the above quoted text:
"they were under constant assault from their clients to use oracle or db2"
Last I looked neither Oracle or DB2 were open source, but they both just
happen to be commercial and I don't see mysql mentioned.
And ?
Regar
On 7 Dec 2002, Rod Taylor wrote:
>
> > What too many people fail to realize is that in a commercial environment
> > many companies want another company to point the finger at in case of
> > disaster. Sybase failed, or HP failed, or IBM failed, or Microsoft
> > failed. They feel they can do somet
On Sun, 8 Dec 2002, Justin Clift wrote:
> Vince Vielhaber wrote:
> > On Thu, 5 Dec 2002, Robert Treat wrote:
> >
> >
> >>Well, my previous employer uses postgresql, but they were under constant
> >>assault from their clients to use oracle or db2. Technically there was no
> >>reason to switch, but
Looking at my problem with changed cursor behaviour in 7.3 again, I
noticed something interesting: a cursor in 7.3 apparently does not let
you scroll back to its first row at all! Neither a "move backward all"
or a "move -n" where n is equal to or greater than the cursor's current
position, will
I'm working on the TODO item "Allow easy display of usernames in a group" in
the context of a slightly larger effort to improve usability of arrays. I'm
far enough down the road to have a better idea of where I want to go with
this, but I'd like to vet those ideas with the list so I don't waste
Yes i found this bug earlier.
There is a patch for it in the mail archives.
Magnus
Argo Priivits <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a problem with contrib/tsearch module.
>
> Simple select txt2txtidx('2-3') causes psql to crash with error:
>
> server closed the connection unexpectedly
The notes below are the results of various tuning issues experienced
recently on a large database (several GB) that has many tables and a high
transient data flow (ie. thousands of records added, updated, and deleted
every hour) on a few tables. This kind of data flow is not at all well
handle
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > It is not real clear to me whether we need a major version bump, rather
> > than a minor one. We *do* need to signal binary incompatibility. Who
> > can clarify the rules here?
>
> Strictly speaking, it's platform-dependent, but our shared librar
34 matches
Mail list logo
