Can I safely assume that the OID of the standard data types remain the same
for future releases? And of course that they are the same for every
installation?
I've been send a patch to speed up ecpg significantly by not looking up
datatypes everytime. As it is written right now it works by har cod
At 04:41 15/09/00 -0500, Jan Wieck wrote:
>
>So if you find an ON SELECT rule on a relation, it is a VIEW.
>
Thanks for this, but I'm using 'pg_views' now since it means pg_dump does
not have to interpret the meanings of the various columns. With time, I
would like to remove as much internal
It seems that foreign key does not work in current, if specified with
primary key definition. Take a look at following example(works in
7.0.2.):
test=# CREATE TABLE PKTABLE ( ptest1 int, ptest2 int, ptest3 int, ptest4 text, PRIMARY
KEY(ptest1, ptest2, ptest3) );
NOTICE: CREATE TABLE/PRIMARY KEY
I just did a cvsup to get up-to-date again after I hadn't found time to work
on ecpg for some months and found out that I cannot even compile anymore:
make[3]: Entering directory /home/postgres/pgsql/src/backend/parser'
gcc -MM -I../../../src/include -O2 -Wall -Wmissing-prototypes -Wmissing-decl
Michael Meskes <[EMAIL PROTECTED]> writes:
> Can I safely assume that the OID of the standard data types remain the same
> for future releases? And of course that they are the same for every
> installation?
They are fixed in any one version, and really are not very likely to
change across version
Michael Meskes <[EMAIL PROTECTED]> writes:
> What's going on?
I'd suggest a full "make distclean" and reconfigure. Looks like you
missed some build steps, which is maybe not too surprising considering
that Peter has extensively revised the Makefile tree.
regards, tom lan
On Fri, 15 Sep 2000, Tatsuo Ishii wrote:
> It seems that foreign key does not work in current, if specified with
> primary key definition. Take a look at following example(works in
> 7.0.2.):
>
> test=# CREATE TABLE PKTABLE ( ptest1 int, ptest2 int, ptest3 int, ptest4 text,
>PRIMARY KEY(ptest1
Hello Stephan,
I think this listserver hates me. none of my messages seem to go through.
Anyone read this ??
I need to get access to records that is marked expired in the database any
idea how or if it's possible ?
Please respond even if it's just to say that you don't know so I KNOW that
my
On Tue, Sep 12, 2000 at 09:42:41AM +0200, Zeugswetter Andreas SB wrote:
>
> add the functionality for "with check option" clause of create view
>
I'm not familiar with this. What does it do?
--
Mark Hollomon
[EMAIL PROTECTED]
Does anyone have the Sept issue of Linux Magazine? According to a
notification we just received, PostgreSQL got 4th place in the editor's
choice awards. I wanna know what was in first, second and third!
Anyone know?
Vince.
--
==
Your message got though. I don't know the answer to your question, but
I'll bet that it is NO.
On Fri, 15 Sep 2000, Eje Gustafsson wrote:
> Hello Stephan,
>
> I think this listserver hates me. none of my messages seem to go through.
> Anyone read this ??
>
> I need to get access to records th
1st - MySQL
2nd - Oracle 8i
3rd - Informix Dynamic Server.2000
-Original Message-
From: Vince Vielhaber <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, September 15, 2000 1:31 PM
Subject: [HACKERS] Winner Notification - Linux Magazine Editor's Choice
Awards (f
*rofl* now that wasn't rigged or nothing ... I could see us second to
MySQL, or third to Oracle/Informix, depending on how it was evaluated, but
fourth to all three?
On Fri, 15 Sep 2000, Len Morgan wrote:
> 1st - MySQL
> 2nd - Oracle 8i
> 3rd - Informix Dynamic Server.2000
>
>
> -Original
I finished revising the LIKE operators back into an index-optimizable
form. But I notice there is some non-multibyte-aware code that needs
to be fixed, specifically the pattern analysis routines in
src/backend/utils/adt/selfuncs.c:
like_fixed_prefix
regex_fixed_prefix
like
Hasn't the [HACKERS] / [GENERAL] crossover thing been resolved yet? I'm
not subscribed to hackers.
Tom Lane wrote:
>
> I finished revising the LIKE operators back into an index-optimizable
> form. But I notice there is some non-multibyte-aware code that needs
> to be fixed, specifically the pa
The Hermit Hacker wrote:
>
> *rofl* now that wasn't rigged or nothing ... I could see us second to
> MySQL, or third to Oracle/Informix, depending on how it was evaluated, but
> fourth to all three?
Hey, look at the headline:
Linux Magazine's Editor's Choice Awards
by The Edi
On Fri, 15 Sep 2000, Jan Wieck wrote:
> The Hermit Hacker wrote:
> >
> > *rofl* now that wasn't rigged or nothing ... I could see us second to
> > MySQL, or third to Oracle/Informix, depending on how it was evaluated, but
> > fourth to all three?
>
> Hey, look at the headline:
>
> L
> I finished revising the LIKE operators back into an index-optimizable
> form. But I notice there is some non-multibyte-aware code that needs
> to be fixed, specifically the pattern analysis routines in
> src/backend/utils/adt/selfuncs.c:
> like_fixed_prefix
> regex_fixed_prefix
>
Hi,
I am tring to use the qnx version of postgresql
7.0.0
I have qnx 4.25 and TCP/IP
I have compiled postgres using gcc
I used this commands
gmake all
gmake install
then I have started postgres with -D and -i
options.
Every time I execute the command createdb I have
SIGSEGV error.
19 matches
Mail list logo
