The Hermit Hacker <[EMAIL PROTECTED]> writes:
> GNUMakefile.in:
> opt_files := \
> src/tools src/corba src/data src/tutorial \
Ah.
> I take it then, that src/data shoudl be removed from there too?
Yep. Sorry I missed it.
regards, tom lane
--
--On Monday, August 04, 2003 23:01:32 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
As soon as a beta tarball shows up, I'll cut changes for UnixWare for
--enable-threads,
and also to do -D_REENTRANT anyway on UnixWare.
OK.
What about Kean's change to allow absolute DT_S
GNUMakefile.in:
opt_files := \
src/tools src/corba src/data src/tutorial \
src/bin/pgtclsh \
$(addprefix src/interfaces/, libpgtcl jdbc) \
$(addprefix src/pl/, plperl plpython tcl)
I take it then, that src/data shoudl be removed from there too?
On Mon, 4 Aug 200
Hi,
Is it possible to get a default value on a boolean column to be anything
other than 't', 'f', true or false?
eg. If I go 'default 3 > 1', that's resolved to default true.
I just need to know for phpPgAdmin...
Chris
---(end of broadcast)---
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Using the attached script, the build fails while trying ot tar up the
> distributions ... when its trying to build the tools tar file, error being
> that it can't find the src/data directory ...
Why is it looking for src/data? I removed all the file
> > That will fail for a more basic reason: not all compilers support the -o
> > option.
>
> I added sub-Makefiles. Christopher, try now, pls.
Works perfectly. Thanks.
Chris
---(end of broadcast)---
TIP 8: explain analyze is your friend
As soon as a beta tarball shows up, I'll cut changes for UnixWare for
--enable-threads,
and also to do -D_REENTRANT anyway on UnixWare.
What about Kean's change to allow absolute DT_SONAME's?
Can that get applied, and used for SCO and UnixWare?
LER
--On Monday, August 04, 2003 18:16:02 -0400 B
On Monday 04 August 2003 13:57, Joe Conway wrote:
> I just checked, and the RHAS that I built the RPMs on is pretty close to
> original, other than kernel and some driver updates. I'll let you decide
> whether to pull them or not, but they don't meet your "fully-updated
> install" criterion.
Hmmm.
Good question. If you send over the patches, we will apply it to the
version we ship.
---
[EMAIL PROTECTED] wrote:
> Is anyone actively maintaining the dbase/dbf2pg utility in the
> contrib library? I have a couple of pat
> Let's not go there. I'm not involved in the IP fight, but I am a USER on
> that
> platform, and SCO is thinking SERIOUSLY about shipping PG on the
> Platform
> as part of their extensions offering.
>
> What the fr*** harm is it in passing -D_REENTRANT into the libpq build on
> UnixWa
Would you send over a modified template/unixware and template/sco to at
least allow threading when enabled --- see linux or freebsd for examples
--- that is how we are enabling threading.
Are you saying you want that flag without --enable-thread-safety?
--
Julian Satchell <[EMAIL PROTECTED]> writes:
> The implementations of lower and upper in
> src/backend/utils/adt/oracle_compat.c use the single byte macros from
> ctype.h to alter individual bytes in the text string.
> If the text is UTF-8 encoded this is totally wrong, and will result in
> an inv
The implementations of lower and upper in
src/backend/utils/adt/oracle_compat.c use the single byte macros from
ctype.h to alter individual bytes in the text string.
If the text is UTF-8 encoded this is totally wrong, and will result in
an invalid string that is no longer UTF-8.
The code is basi
drop relation = drop table or drop sequence etc
I tryed RelationForgetRelation() but i dont working :(
On Mon, 4 Aug 2003, Alvaro Herrera wrote:
> On Mon, Aug 04, 2003 at 09:24:49PM +0200, ivan wrote:
> >
> > hi, i have more problems with cache :( i wrote about it latter , but there
> > was no a
Peter Eisentraut writes:
> Tom Lane wrote:
>> Clients could probably still make use of server_encoding, though I'm
>> unclear on what they'd use it for now, let alone then. ISTM
>> client_encoding is the only setting the client need deal with directly.
> Then why did we add a GUC variable "server
On Mon, Aug 04, 2003 at 09:24:49PM +0200, ivan wrote:
>
> hi, i have more problems with cache :( i wrote about it latter , but there
> was no answer. Because when i drop same relation its should be clean cache
> too, but postgres dont do it . Ist sad because i cant do reload db , i
> have errors :
On Mon, 4 Aug 2003, Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > SCO is thinking SERIOUSLY about shipping PG on the Platform as
> > part of their extensions offering.
>
> Why, how nice of them. I don't intend to lift a finger to help.
I don't know, I can think of ONE
hi, i have more problems with cache :( i wrote about it latter , but there
was no answer. Because when i drop same relation its should be clean cache
too, but postgres dont do it . Ist sad because i cant do reload db , i
have errors :( what should i do ?
---(end of broadca
--On Monday, August 04, 2003 14:06:34 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
SCO is thinking SERIOUSLY about shipping PG on the Platform as
part of their extensions offering.
Why, how nice of them. I don't intend to lift a finger to help.
G
Larry Rosenman <[EMAIL PROTECTED]> writes:
> SCO is thinking SERIOUSLY about shipping PG on the Platform as
> part of their extensions offering.
Why, how nice of them. I don't intend to lift a finger to help.
regards, tom lane
---(end of b
Joe Conway wrote:
Lamar Owen wrote:
I've thus far used the definition that it is a fully-updated install,
using the OS vendor's update packages that are dependencies of
PostgreSQL. Updating to, say, a later KDE, or GNUcash, or whatnot is
OK. But core libraries that PostgreSQL uses need to stay
Is anyone actively maintaining the dbase/dbf2pg utility in the
contrib library? I have a couple of patches to fix bugs and one
feature enhancement to suggest, but I'm not sure of the proper
procedure for a contrib package.
I've tried contacting the author at the address given in the package
([
I agree with the definition of "vanilla install" below.
I can't use the machine I was upgrading to build, unfortunately. Its a
production machine I am prepping, (and is missing stuff the build
process needs even if I wanted to monkey with it), which is precisely
why I wanted to install from RPM
Lee Kindness <[EMAIL PROTECTED]> writes:
> Would I be right is guessing a binary CURSOR would return in values in
> the same format as a binary COPY, hence your expectation of more
> individual transfers/conversions? Actually with the new FE/BE protocol
> there is little call for the binary cursor
--On Monday, August 04, 2003 13:19:57 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
> Larry Rosenman wrote:
>> >> > We decided to make separate thread/nonthread libraries if the
>> >> >
Larry Rosenman wrote:
>
>
> --On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> > Larry Rosenman wrote:
> >> >> > We decided to make separate thread/nonthread libraries if the
> >> >> > threading requires any special flags --- we haven't done that yet,
> >
Lamar Owen wrote:
On Monday 04 August 2003 13:00, Joe Conway wrote:
I don't think so -- the server I built those on is very much vanilla
RHAS. But then this raises a question in my mind -- is vanilla a fully
updated vanilla or "off the original CDs" vanilla?
I've thus far used the definition that
On Monday 04 August 2003 13:00, Joe Conway wrote:
> I don't think so -- the server I built those on is very much vanilla
> RHAS. But then this raises a question in my mind -- is vanilla a fully
> updated vanilla or "off the original CDs" vanilla?
I've thus far used the definition that it is a full
--On Monday, August 04, 2003 13:11:45 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
>> > We decided to make separate thread/nonthread libraries if the
>> > threading requires any special flags --- we haven't done that yet,
>> > and only configure controls it.
>> That will
Larry Rosenman wrote:
> >> > We decided to make separate thread/nonthread libraries if the threading
> >> > requires any special flags --- we haven't done that yet, and only
> >> > configure controls it.
> >> That will be a POLA (principle of least astonishment) violation on
> >> UnixWare.
> >
> >
--On Monday, August 04, 2003 12:50:31 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Monday, August 04, 2003 12:30:32 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
> We decided to make separate thread/nonthread libraries if the threading
> requires any special fl
Lamar Owen wrote:
Joe, the RHAS binaries won't have this problem, right?
I don't think so -- the server I built those on is very much vanilla
RHAS. But then this raises a question in my mind -- is vanilla a fully
updated vanilla or "off the original CDs" vanilla?
To prevent this in the future, I
On Monday 04 August 2003 11:53, Joe Conway wrote:
> Andrew Dunstan wrote:
> > I know building RPMs can be a major pain, but ISTM that builds should be
> > published that don't break on vanilla installations. I'm prepared to
> > help with fixing this if necessary. For now I've upgraded to 7.3.3 (the
On Mon, 2003-08-04 at 12:19, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This this a TODO? Keep in mind if we follow the syntax of VACUUM and
> > (7.4) CLUSTER, that the all-database truncate would just be "TRUNACATE".
> > That seems very risky to me. I wonder if the risk is w
OK, I fixed a number of problems in configure with threads --- please
give it a try now. Thanks.
---
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Peter Eisentraut wrote:
> > > Is it intended that libpq is always c
Larry Rosenman wrote:
>
>
> --On Monday, August 04, 2003 12:30:32 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> >
> > We decided to make separate thread/nonthread libraries if the threading
> > requires any special flags --- we haven't done that yet, and only
> > configure controls it.
>
Tom,
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > However, is COPY BINARY meant/designed to be used as transfer or
> > backup mechanism?
>
> I think you're overlooking a key consideration: COPY BINARY is not
> an isolated feature anymore. By design it uses the same data
Guys,
> I wouldn't care for that either. The prior suggestion of "TRUNCATE tab
> CASCADE" (to truncate any tables with FK dependencies on the original
> target, instead of failing) seems more reasonable.
I agree with Tom ... even the idea of a "TRUNCATE ALL" makes me nervous. If
we had such a
--On Monday, August 04, 2003 12:30:32 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
We decided to make separate thread/nonthread libraries if the threading
requires any special flags --- we haven't done that yet, and only
configure controls it.
That will be a POLA (principle of least astonishm
We decided to make separate thread/nonthread libraries if the threading
requires any special flags --- we haven't done that yet, and only
configure controls it.
---
Larry Rosenman wrote:
>
>
> --On Monday, August 04, 2003
On 4 Aug 2003 at 10:03, scott.marlowe wrote:
> I agree, a plain truncate blasting a whole database is a very bad thing.
>
> however, "truncate with cascade" would be quite useful.
If we could get something simple as getting schema of a table, dropping the
table and recreating empty table, then
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This this a TODO? Keep in mind if we follow the syntax of VACUUM and
> (7.4) CLUSTER, that the all-database truncate would just be "TRUNACATE".
> That seems very risky to me. I wonder if the risk is worth adding this
> feature.
I wouldn't care for that
I agree, a plain truncate blasting a whole database is a very bad thing.
however, "truncate with cascade" would be quite useful.
On Mon, 4 Aug 2003, Bruce Momjian wrote:
>
> This this a TODO? Keep in mind if we follow the syntax of VACUUM and
> (7.4) CLUSTER, that the all-database truncate wou
--On Monday, August 04, 2003 17:54:41 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Bruce Momjian writes:
Peter Eisentraut wrote:
> Is it intended that libpq is always compiled with the so-called
> "thread-safe" compiler option, regardless of whether I used
> --enable-thread-thing?
It cert
Bruce Momjian writes:
> Peter Eisentraut wrote:
> > Is it intended that libpq is always compiled with the so-called
> > "thread-safe" compiler option, regardless of whether I used
> > --enable-thread-thing?
>
> It certainly should not be doing that, but my OS has no thread flags, so
> I am not see
Andrew Dunstan wrote:
I know building RPMs can be a major pain, but ISTM that builds should be
published that don't break on vanilla installations. I'm prepared to
help with fixing this if necessary. For now I've upgraded to 7.3.3 (the
RPMs for this don't suffer the same problem on RH7.3).
Sorr
Peter Eisentraut wrote:
> Is it intended that libpq is always compiled with the so-called
> "thread-safe" compiler option, regardless of whether I used
> --enable-thread-thing?
It certainly should not be doing that, but my OS has no thread flags, so
I am not seeing it here. What exactly do you se
(Not sure if hackers is the right place for this, but I'm not subscribed
to all the lists!)
The distributed 7.3.4 RPMs for RH 7.3 require libcrypto.so.3 and
libssl.so.3, but there does not appear to be any official RH update for
7.3 containing these libs. I do have the latest RH openssl updates
This this a TODO? Keep in mind if we follow the syntax of VACUUM and
(7.4) CLUSTER, that the all-database truncate would just be "TRUNACATE".
That seems very risky to me. I wonder if the risk is worth adding this
feature.
-
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> No, a view is not a table. Try putting an index or trigger on it.
>
> > According to that logic, a domain is not a type. Try putting a check
> > constraint on it.
>
> But that's an additional feature, not a
Peter Eisentraut wrote:
Tom Lane writes:
I was afraid it was something like that. Can we leave the directory
structure as-is and just make the .o (and .d) files get built in the
upper directory, that is
gcc ... -o english_stem.o snowball/english_stem.c
That will fail for a more basic
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> No, a view is not a table. Try putting an index or trigger on it.
> According to that logic, a domain is not a type. Try putting a check
> constraint on it.
But that's an additional feature, not a missing feature.
I think the r
Hi all,
last week ( 27/7/2003 ) I did a post with subj:
"postmaster core ( finally I have it )",
at that time I was supspecting that the core was caused by
a select on a view ( the view is always the same that cause the core )
that was running together with a vacuum; Tom Lane told me that
is reall
On Mon, 2003-08-04 at 10:28, Rod Taylor wrote:
> > Truncate isn't transaction safe either, so that shouldn't be a
> problem.
>
> Actually, it is in 7.4
yeah i know, but I assumed he wasn't doing his production unit testing
against 7.4. Course if he is all the better I suppose... :-)
>
> > Prop
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> Why not? A domain *is* a type, by any reasonable test.
>
> > According to that logic, a view is a table, but we still require DROP VIEW
> > to drop a view.
>
> No, a view is not a table. Try putting an inde
> Truncate isn't transaction safe either, so that shouldn't be a problem.
Actually, it is in 7.4
> Proper syntax for his feature would seem like:
> truncate table [cascade|restrict] ?
Agreed.
signature.asc
Description: This is a digitally signed message part
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> On Mon, 4 Aug 2003, Christopher Kings-Lynne wrote:
>> Oleg - have you followed the latest discussion on why tsearch2 isn't
>> compilable on FreeBSD?
> Nop, Teodor's development machine is FreeBSD and he has no problem :)
I think the problem may only occ
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Why not? A domain *is* a type, by any reasonable test.
> According to that logic, a view is a table, but we still require DROP VIEW
> to drop a view.
No, a view is not a table. Try putting an index or trigger on it.
Is it intended that libpq is always compiled with the so-called
"thread-safe" compiler option, regardless of whether I used
--enable-thread-thing?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe com
Tom Lane writes:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > I notice you can use the 'DROP TYPE' syntax to drop a domain. Should that
> > be allowed?
>
> Why not? A domain *is* a type, by any reasonable test.
According to that logic, a view is a table, but we still require DROP
On Mon, 2003-08-04 at 05:40, Shridhar Daithankar wrote:
> On 4 Aug 2003 at 11:25, Andreas wrote:
> > Would it be possible to implement a "truncate all" that purges all tuples
> > from *all* tables, without taking account any rules or triggers, but
> > leaving all table structures and rules, t
Lee Kindness <[EMAIL PROTECTED]> writes:
> However, is COPY BINARY meant/designed to be used as transfer or
> backup mechanism?
I think you're overlooking a key consideration: COPY BINARY is not
an isolated feature anymore. By design it uses the same data
representations as are used for binary qu
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I notice you can use the 'DROP TYPE' syntax to drop a domain. Should that
> be allowed?
Why not? A domain *is* a type, by any reasonable test.
regards, tom lane
---(end of broadcast)
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <[EMAIL PROTECTED]> writes:
> On Sun, 3 Aug 2003, Tom Lane wrote:
>> I added code to inline_function to stop inlining if a parameter
>> expression to be substituted multiple times has cost greater than
>> 10*cpu_operator_cost (which roughly means that it contains
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Well in that case the docs need attention. They describe the
> > "envelope" surrounding the tuples, but no mention is made of the
> > format they are in. It is reasonable to assume that this format was
> > the native binary format
On 4 Aug 2003 at 11:25, Andreas wrote:
> Would it be possible to implement a "truncate all" that purges all tuples
> from *all* tables, without taking account any rules or triggers, but
> leaving all table structures and rules, triggers, functions, etc intact
> (sequences do not need to re
Hi!
Would it be possible to implement a "truncate all" that purges all tuples
from *all* tables, without taking account any rules or triggers, but
leaving all table structures and rules, triggers, functions, etc intact
(sequences do not need to reinitialized)?
As far as I understand, the "no
Bruce Momjian wrote:
Here are the changes for 7.4. I am looking for any improvements. This
will be adjusted as we move through beta.
---
Add FOR EACH STATEMENT statement-level triggers (Neil Conway)
AFAICS the current implem
Joe Conway said:
> Hmm, same problem. Looks like PL/pgSQL does the right thing, but
> plpython will crash also. I don't think plperl supports triggers.
Right -- I only had time to implement support for statement-level
triggers in the backend itself and in PL/PgSQL. Thanks for taking the
time to up
69 matches
Mail list logo
