Andrew Sullivan wrote:
>On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
>
>>I'm actually amazed that postgres isn't already using large file
>>support. Especially for tools like dump.
>>
>
>Except it would only cause confusion if you ran such a program on a
>system that didn't it
Hi all,
In 7.2.1, MasterInit script (rserv command) does not work correctly,
because $libdir is not defined in it.
I think $libdir should be replaced in Makefile as below.
Is it correct?
--- MakefileMon Mar 11 13:39:14 2002
+++ /tmp/Makefile Tue Aug 13 18:19:21 2002
@@ -22,10 +22,10
Le Dimanche 11 Août 2002 17:53, Tom Lane a écrit :
> Hmm. I remember Poure asking repeatedly for CREATE OR REPLACE VIEW,
> and that makes a lot of sense to me, because other things *can* depend
> on a view. (Unfortunately, by the same token it's a lot harder to do.)
> The use-case for replacing
On Tue, 2002-08-13 at 03:57, Greg Copeland wrote:
> > Are there any filesystems in common use (not including windows ones) that
> > don't support >32-bit filesizes?
> >
> > Linux (ext2) I know supports by default at least to 2TB (2^32 x 512bytes),
> > probably much more. What about the BSDs? XFS?
> > OK, seeing as no one voted, and only Tom and I objected originally, we
> > will keep the code as Thomas has applied it, namely that PGXLOG/-X is
> > recognized by initdb, postmaster, postgres, and pg_ctl.
>
> We will? It looks to me like Thomas lost the vote 2-to-1.
>
> Unless there are mo
We have a patch for pg_dump which adds a possibility to dump
a part of table, for example:
dump Top.Science.Astronomy heirarchy from dmoz catalog
pg_dump -d -t dmoz -w "select * from dmoz where path <@ 'Top.Science.Astronomy'" dmoz
We found it's very useful. We'd like to extend it to use also w
Hi all,
I'm thinking that temporary views should be pretty trivial to
implement.
* Allow temporary views
This should be as simple as modifying gram.y (to set
ViewStmt->view->istemp) and some logic in RemoveTempRelations() to remove
the view's rule
* Require view using temporary tables to be te
On Tue, 2002-08-13 at 02:47, Jeroen T. Vermeulen wrote:
> On Mon, Aug 12, 2002 at 09:38:00PM -0300, Marc G. Fournier wrote:
> >
> > should be fixed ... looks like just an ownership issue on a new directory
>
>
> More like I uploaded that directory just as you were rsync'ing to
> anonymous CVS a
On Tue, 2002-08-13 at 07:49, Oleg Bartunov wrote:
> We have a patch for pg_dump which adds a possibility to dump
> a part of table, for example:
>
> dump Top.Science.Astronomy heirarchy from dmoz catalog
>
> pg_dump -d -t dmoz -w "select * from dmoz where path <@ 'Top.Science.Astronomy'" dmoz
>
On 13 Aug 2002, Rod Taylor wrote:
> On Tue, 2002-08-13 at 07:49, Oleg Bartunov wrote:
> > We have a patch for pg_dump which adds a possibility to dump
> > a part of table, for example:
> >
> > dump Top.Science.Astronomy heirarchy from dmoz catalog
> >
> > pg_dump -d -t dmoz -w "select * from dmoz
On Mon, 2002-08-12 at 21:07, Peter Eisentraut wrote:
> This is not the only issue. You really need to check all uses of off_t
> (for example printf("%ld", off_t) will crash) and all places where off_t
> should have been used in the first place. Furthermore you might need to
> replace ftell() an
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We will? It looks to me like Thomas lost the vote 2-to-1.
> Well, you didn't vote again in my follow up email,
I thought my vote was obvious already ...
> Can two guys override another guy if he is doing the work? I usually
> like
On Tue, 2002-08-13 at 03:42, Mark Kirkwood wrote:
> Andrew Sullivan wrote:
>
> >On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
> >
> >>I'm actually amazed that postgres isn't already using large file
> >>support. Especially for tools like dump.
> >>
> >
> >Except it would only c
> But I really seriously feel that this feature is a bad idea as presently
> implemented. If necessary, I'll volunteer to change it the way I think
> it should be (viz, initdb can set up a symlink to a specified xlog
> directory; no change from previous behavior anywhere else).
Neither solution
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
>> I think Tom is on to something here. I meant to ask but never got
>> around to it. Why would anyone need to move the XLOG after you've
>> inited the db?
> I just determined that disk I/O is terrible, so want to move the XLOG over
> to a differen
On Tue, Aug 13, 2002 at 08:02:05AM -0500, Larry Rosenman wrote:
> On Tue, 2002-08-13 at 03:42, Mark Kirkwood wrote:
> > Other operating systems where 64 bit file access can be disabled or
> > unconfigured require more care - possibly (sigh) 2 binary RPMS with a
> > distinctive 32 and 64 bit lab
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> In the spirit of gratutious overstatement, I'll point out again:
> symlinks are evil.
Please justify that claim. They work really nicely in my experience...
and I don't know of any modern Unix system that doesn't rely on them
*heavily*.
Possibly mor
> Looking at how to deal with this, is the following going to be
> portable?:
>
> in pg_dump/Makefile:
> CFLAGS += -D_LARGEFILE_SOURCE -D_OFFSET_BITS=64
>
> in pg_dump.h:
> #ifdef _LARGEFILE_SOURCE
> #define FSEEK fseeko
> #define FTELL ftello
> #define
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> One thought at the back of my mind is why not have something like a
> 'PG_VERSION' for XLOG? Maybe something so simple as a text file in both
> the data and xlog directory that just contains a timestamp from the
> initdb? then, when you startup p
Hi,
this is an announcement of OpenFTS 0.33 release.
Please, find archive in download area at openfts.sourceforge.net
This is a major release ! It has a lot of enhancements.
It's required PostgreSQL 7.2.1 (7.2.2 from CVS would be better)
Some major changes:
1. We moved from using contrib/intar
On Tue, 2002-08-13 at 08:15, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> I think Tom is on to something here. I meant to ask but never got
> >> around to it. Why would anyone need to move the XLOG after you've
> >> inited the db?
>
> > I just determined that disk I/O i
Greg Copeland wrote:
> On Tue, 2002-08-13 at 00:16, Curt Sampson wrote:
>
>>I will revise my opinion the instant someone shows me something that I
>>can't do relationally, or is easy to implement with inheritance, and
>>difficult with relational methods.
The traditional view approach requires un
On Tue, 2002-08-13 at 14:15, Tom Lane wrote:
> 4. ln -s new xlog directory to $PGDATA/xlog
> With the patch it's almost the same, but you can instead of (4) substitute
>
> (4a) Change PGXLOG environment variable or -X argument in start script.
>
> That is *not* materially easier than an "ln" i
Rod Taylor <[EMAIL PROTECTED]> writes:
> Symlinks seem to break all over the place (windows, novell, os/2),
The portability argument carries little weight with me. Recent versions
of Windows have symlinks. If anyone wants to run a PG installation on
a symlink-less platform, okay; they just won'
On Tue, 2002-08-13 at 14:26, Zeugswetter Andreas SB SD wrote:
>
> > Looking at how to deal with this, is the following going to be
> > portable?:
> No, look at the int8 code to see how to make it portable.
> On AIX e.g it is %lld and long long int.
OK. %lld is usable by glibc, so amend %Ld to
On Tue, 2002-08-13 at 14:24, Tom Lane wrote:
...
> But there's more than one way to record the xlog location in the data
> directory. If you don't like a symlink, what of putting it in
> postgresql.conf as a postmaster-start-time-only config option?
Please don't!
The Debian package at least pro
On Tuesday 13 August 2002 01:40 am, Greg Copeland wrote:
> On Tue, 2002-08-13 at 00:33, Curt Sampson wrote:
> > On Mon, 12 Aug 2002, Don Baccus wrote:
> > > Give it up. You're acting like a turkey. If you aren't, skin yourself
> > > a new non-turkey skin.
> > Since he appears not to be able to
Oliver Elphick <[EMAIL PROTECTED]> writes:
> Could you not store the location of the xlog directory as an entry in
> $PGDATA/global/pg_control?
We could do that *only* if we were to produce an xlog-moving program
immediately; otherwise we've regressed in functionality compared to
prior releases.
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Tue, 2002-08-13 at 14:24, Tom Lane wrote:
>> But there's more than one way to record the xlog location in the data
>> directory. If you don't like a symlink, what of putting it in
>> postgresql.conf as a postmaster-start-time-only config option?
>
When I attaempt to compile the lastest cvs version I get the following error
gmake[4]: Entering directory
`/usr/local/postgres/pgsql/src/backend/utils/mb/conversion_procs/utf8_and_ascii'
gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../../../src/include -I/usr/loca
On Tue, 2002-08-13 at 15:00, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > Could you not store the location of the xlog directory as an entry in
> > $PGDATA/global/pg_control?
>
> We could do that *only* if we were to produce an xlog-moving program
> immediately; otherwise we'v
Oliver Elphick <[EMAIL PROTECTED]> writes:
> Looking at how to deal with this, is the following going to be
> portable?:
> #define OFF_T_FORMAT %Ld
That certainly will not be. Use INT64_FORMAT from pg_config.h.
> typedef long int OFF_T;
Why not just use off_t? In both cases?
On Tue, 2002-08-13 at 15:23, Tom Lane wrote:
> > typedef long int OFF_T;
>
> Why not just use off_t? In both cases?
The prototype for fseek() is long int; I had assumed that off_t was not
defined if _LARGEFILE_SOURCE was not defined.
--
Oliver Elphick[EM
Oliver Elphick <[EMAIL PROTECTED]> writes:
>> Marc's idea of matching signature files would be a better
>> safety-checking mechanism than just making the data directory's xlog
>> link hard to get at.
> I would like to have Marc's safeguards as well.
Yeah, I was lukewarm about that at first, but
Yea, the problem with postgresql.conf is that we don't have any
automatic modifications of that file, and I don't think we want to start
just to avoid symlinks.
I personally like symlinks too. I use them all the time. What is the
problem with them, exactly? Can someone show me some commands t
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Tue, 2002-08-13 at 15:23, Tom Lane wrote:
>> Why not just use off_t? In both cases?
> The prototype for fseek() is long int; I had assumed that off_t was not
> defined if _LARGEFILE_SOURCE was not defined.
Oh, you're right. A quick look at HPUX s
Gavin Sherry wrote:
> Hi all,
>
> I'm thinking that temporary views should be pretty trivial to
> implement.
>
> * Allow temporary views
>
> This should be as simple as modifying gram.y (to set
> ViewStmt->view->istemp) and some logic in RemoveTempRelations() to remove
> the view's rule
Yep, p
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I'm thinking that temporary views should be pretty trivial to
> implement.
... except not so trivial, per the rest of your note.
Do we actually need any such feature? Views on temp tables already work
correctly in CVS tip: the implicit DROP CASCADE on
On Tue, 2002-08-13 at 11:11, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > I'm thinking that temporary views should be pretty trivial to
> > implement.
>
> ... except not so trivial, per the rest of your note.
>
> Do we actually need any such feature? Views on temp tables alrea
CHANGES:
August 13, 2002
Use parser of OpenFTS v0.33.
--
Teodor Sigaev
[EMAIL PROTECTED]
tsearch_patch.gz
Description: application/gzip
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
to current CVS, of course. Sorry
--
Teodor Sigaev
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > I'm thinking that temporary views should be pretty trivial to
> > implement.
>
> ... except not so trivial, per the rest of your note.
>
> Do we actually need any such feature? Views on temp tables already work
> correctly in CVS ti
Rod Taylor <[EMAIL PROTECTED]> writes:
> I was playing with this a while back (when I had initially added CASCADE
> to tables). I believe that in the event of a crash the temp tables are
> not removed until their next use. This means that stale *real* items
> may litter the system but the temp t
On Tue, 2002-08-13 at 12:22, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I was playing with this a while back (when I had initially added CASCADE
> > to tables). I believe that in the event of a crash the temp tables are
> > not removed until their next use. This means that stal
On Tue, 2002-08-13 at 11:18, Bruce Momjian wrote:
> Tom Lane wrote:
> > Gavin Sherry <[EMAIL PROTECTED]> writes:
> > > I'm thinking that temporary views should be pretty trivial to
> > > implement.
> >
> > ... except not so trivial, per the rest of your note.
> >
> > Do we actually need any such
This patch seems extremely messy to me. Unless I'm missing something,
-w just plain fails except when you are dumping a specific table (ie,
-t must be given as well). And heaven help you if you specify a
different table in -t than the one -w is selecting from. This isn't
well thought out.
I'm
On Mon, 12 Aug 2002, Thomas Lockhart wrote:
> > If you move pg_xlog, you have to create a symlink in /data that points
> > to the new location. Initdb would do that automatically, but if you
> > move it after initdb, you would have to create the symlink yourself.
> > With Thomas's current code,
Rod Taylor wrote:
> On Tue, 2002-08-13 at 11:18, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Gavin Sherry <[EMAIL PROTECTED]> writes:
> > > > I'm thinking that temporary views should be pretty trivial to
> > > > implement.
> > >
> > > ... except not so trivial, per the rest of your note.
> > >
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I can go either way on this.
AFAICS "create temp view" would have some small advantage of keeping the
view's name out of possibly-public permanent namespaces, so the step of
just adding the TEMP option to CREATE VIEW may be worth doing. The
advantage i
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I can go either way on this.
>
> AFAICS "create temp view" would have some small advantage of keeping the
> view's name out of possibly-public permanent namespaces, so the step of
> just adding the TEMP option to CREATE VIEW may be w
Oliver Elphick wrote:
> On Tue, 2002-08-13 at 03:57, Greg Copeland wrote:
>>Ext2 & 3 should be okay. XFS (very sure) and JFS (reasonably sure)
>>should also be okay...IIRC. NFS and SMB are probably problematic, but I
>>can't see anyone really wanting to do this.
>
> Hmm. Whereas I can't see ma
Tom Lane wrote:
>
>Also, for Mario and Barry: does this test case look anything like what
>your real applications do? In particular, do you ever do a SELECT FOR
>UPDATE in a transaction that commits some changes, but does not update
>or delete the locked-for-update row? If not, it's possible
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What about indexes? Do indexes on temp tables exist in the temp
> namespace?
Yes, a fortiori: any index exists in its table's namespace. Seems
pretty irrelevant to the point at hand, though.
regards, tom lane
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Teodor Sigaev wrote:
> CHANGES:
>
> August 13
On Tue, 13 Aug 2002, Tom Lane wrote:
> This patch seems extremely messy to me. Unless I'm missing something,
> -w just plain fails except when you are dumping a specific table (ie,
> -t must be given as well). And heaven help you if you specify a
> different table in -t than the one -w is selec
Dear all,
The current implementation of views uses OIDs, not table/view names. As
a consequence, when you happen to replace (drop then create) an
underlying table or view, you also have to drop and recreate all views
using this table|view (and this recursively, of course ...).
I stumbled on t
Emmanuel Charpentier <[EMAIL PROTECTED]> writes:
> What do you think ?
I think Gavin Sherry is already working on this.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Hannu Krosing wrote:
> On Wed, 2002-08-14 at 04:08, Emmanuel Charpentier wrote:
>
>>Dear all,
>>
>
> ...
>
>
>>Of course, I am aware that view definitions aren't just stored, but that
>> a lot of rewriting is involved before storing the actual execution
>>plan.Modifying a view definitio
Tom,
I submitted a patch for this a few days ago. Did it not hit pgsql-patches?
Gavin
On Tue, 13 Aug 2002, Tom Lane wrote:
> Emmanuel Charpentier <[EMAIL PROTECTED]> writes:
> > What do you think ?
>
> I think Gavin Sherry is already working on this.
>
> regards, tom la
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What about indexes? Do indexes on temp tables exist in the temp
> > namespace?
>
> Yes, a fortiori: any index exists in its table's namespace. Seems
> pretty irrelevant to the point at hand, though.
Just checking. So the index ex
Hannu Krosing wrote:
> On Wed, 2002-08-14 at 04:23, Emmanuel Charpentier wrote:
>
>>Hannu Krosing wrote:
>>
>>>I'm trying to propose a scenario where
>>>
>>>1. The SELECT clause defining the view is preserved
>>>
>>>2. DROP of undrlying table/column will _not_ drop the view, but just
>>>mark it
> Tradeoffs, again ... What about emitting warnings after table drop
> (easy)/creation (not so easy !) ?
The warnings are certainly there now. Dependency code won't let you do
such a thing without specifying CASCADE.
Hopefully CREATE OR REPLACE VIEW will be applied soon, which solves part
two
On Tue, 2002-08-13 at 17:11, Rod Taylor wrote:
> > I wouldn't totally discount using NFS for large databases. Believe it or
> > not, with an Oracle database and a Network Appliance for storage, NFS is
> > exactly what is used. We've found that we get better performance with a
> > (properly tune
Oliver Elphick <[EMAIL PROTECTED]> writes:
> But large file support is not really an issue for the database itself,
> since table files are split at 1Gb. Unless that changes, the database
> is not a problem.
I see no really good reason to change the file-split logic. The places
where the backen
On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote:
>
> I see no really good reason to change the file-split logic. The places
> where the backend might possibly need large-file support are
> * backend-side COPY to or from a large file
I _think_ this causes a crash. At least, I _th
Marc G. Fournier writes:
> Okay, but if we are going to pull libpqxx, what about the other lib's too?
Certain things apply to libpqxx that don't all apply to the others libs:
It is maintained and developed independently anyway. It's new and not
integrated yet. It's a different programming lang
With the new dependency system we have the entire system catalog content
pinned down and unchangeable. This is a tiny dent in the nice extensible
nature of the system.
Would it be feasible to identify the non-essential parts of the built-in
objects (say, inet type, numeric type, associated funct
On Tue, 13 Aug 2002, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > > I think Tom is on to something here. I meant to ask but never got
> > > around to it. Why would anyone need to move the XLOG after you've
> > > inited the db?
> >
> > I just determined that disk I/O is terrible, so want t
Peter Eisentraut wrote:
> With the new dependency system we have the entire system catalog content
> pinned down and unchangeable. This is a tiny dent in the nice extensible
> nature of the system.
>
> Would it be feasible to identify the non-essential parts of the built-in
> objects (say, inet
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Marc G. Fournier writes:
>> Okay, but if we are going to pull libpqxx, what about the other lib's too?
> Certain things apply to libpqxx that don't all apply to the others libs:
> It is maintained and developed independently anyway. It's new and not
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> With the new dependency system we have the entire system catalog content
> pinned down and unchangeable. This is a tiny dent in the nice extensible
> nature of the system.
It's still "extensible", it's just not so easily "contractible"...
I'm not s
On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote:
> On a system where building with large-file support is reasonably
> standard, I agree that PG should be built that way too. Where it's
> not so standard, I agree with Andrew Sullivan's concerns ...
What do you mean by "standard"? That on
On Tue, Aug 13, 2002 at 06:45:59PM +0100, [EMAIL PROTECTED] wrote:
> support isn't compiled, I didn't see one occuring from any application
> having the support, but not the filesystem. (Your "not so standard
Wrong. The symptom is _exactly the same_ if the program doesn't have
the support, the
On Tue, 2002-08-13 at 12:45, [EMAIL PROTECTED] wrote:
> On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote:
> > On a system where building with large-file support is reasonably
> > standard, I agree that PG should be built that way too. Where it's
> > not so standard, I agree with Andrew Su
On Tue, 2002-08-13 at 12:04, Tom Lane wrote:
> On a system where building with large-file support is reasonably
> standard, I agree that PG should be built that way too. Where it's
> not so standard, I agree with Andrew Sullivan's concerns ...
Agreed. This is what I originally asked for.
Gr
I am working on a patch to increase these as agreed. I found this
interesting, from the 6.3 release notes:
Increase 16 char limit on system table/index names to 32 characters(Bruce)
The limited to be 16 chars until 6.3 in 1998-03-01.
On Tue, 2002-08-13 at 20:43, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I can go either way on this.
>
> AFAICS "create temp view" would have some small advantage of keeping the
> view's name out of possibly-public permanent namespaces, so the step of
> just adding the TEMP o
On Tue, 2002-08-13 at 20:24, Tom Lane wrote:
>
> What would seem to make sense is adding a WHERE-clause option to
> COPY TO, and then you could go
> COPY table TO 'myfile' WHERE ...
What about :
COPY table TO 'myfile' [ WHERE cond ] [ AS INSERT [ WITH COLUMN ] ];
to get the data as INSER
On Tue, Aug 13, 2002 at 02:09:07PM -0400, Andrew Sullivan wrote:
> On Tue, Aug 13, 2002 at 06:45:59PM +0100, [EMAIL PROTECTED] wrote:
>
> > support isn't compiled, I didn't see one occuring from any application
> > having the support, but not the filesystem. (Your "not so standard
>
> Wrong. Th
Actually, loading all this stuff into COPY is not the way to go, I
think.
Informix had:
UNLOAD TO 'filename'
SELECT ...
I have to admit, this is a superior way to do thing compared to what we
have. Is is possible for us to get:
COPY TO 'filename'
SELECT ...
> > that TODO item was written before we had dependencies, and I think
> > it's obsolete. Basically the point of the TODO was to avoid
> > having broken views --- and we have solved that problem.
>
> We may have broken views again when "alter table drop column" gets done
Any view depending on a
On Tue, 2002-08-13 at 22:38, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > With the new dependency system we have the entire system catalog content
> > pinned down and unchangeable. This is a tiny dent in the nice extensible
> > nature of the system.
>
> It's still "extensib
On Tue, 2002-08-13 at 18:48, Don Baccus wrote:
> Greg Copeland wrote:
> > On Tue, 2002-08-13 at 00:16, Curt Sampson wrote:
> >
...
>
> And yes I know he's not reading my mail and no, don't bother repeating
> this to him, he'll just continue to ignore the point.
I suspect that he will still rea
On Wed, 2002-08-14 at 00:10, Rod Taylor wrote:
> > > that TODO item was written before we had dependencies, and I think
> > > it's obsolete. Basically the point of the TODO was to avoid
> > > having broken views --- and we have solved that problem.
> >
> > We may have broken views again when "al
Hannu Krosing <[EMAIL PROTECTED]> writes:
> We may have broken views again when "alter table drop column" gets done
It is done, and we do not have broken views.
regression=# create table t (f1 int, f2 int, f3 int);
CREATE TABLE
regression=# create view v as select f1,f2 from t;
CREATE VIEW
regre
On Wed, 2002-08-14 at 00:03, Bruce Momjian wrote:
>
> Actually, loading all this stuff into COPY is not the way to go, I
> think.
>
> Informix had:
>
> UNLOAD TO 'filename'
> SELECT ...
>
> I have to admit, this is a superior way to do thing compared to what we
> have. Is is pos
Hannu Krosing wrote:
> On Wed, 2002-08-14 at 00:03, Bruce Momjian wrote:
> >
> > Actually, loading all this stuff into COPY is not the way to go, I
> > think.
> >
> > Informix had:
> >
> > UNLOAD TO 'filename'
> > SELECT ...
> >
> > I have to admit, this is a superior way to do thing
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Tue, 2002-08-13 at 22:38, Tom Lane wrote:
>> It's still "extensible", it's just not so easily "contractible"...
>>
>> I'm not sure that this matters, as I've never heard of anyone actually
>> troubling to remove unused datatypes etc.
> It could beco
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Clearly, we should shoot for something that leverages the existing
> SELECT code rather than hang more clauses off of COPY.
Yeah, that's a good point. COPY IN is still a special case, I think,
but seems like COPY OUT could be reimplemented as a special
Tatsuo Ishii writes:
> The $libdir variable is defined at the compile time and it points to
> $prefix/lib. Apparently it points to different place while doing
> regression tests. One idea is replacing $lindir with the absolute path
> to $prefix/lib. However I wonder this would break some installa
Satoshi Nagayasu writes:
> I think $libdir should be replaced in Makefile as below.
No, it's correct as is. Read the documentation.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with
> > The attached patch adds CONVERSION stuff for cyrillic and
> > win874/1250/1251/1256 encodings.
>
> Thanks. I'll take care of this.
Done. Documents and regression tests have been updated also. I think
now we have implemented all encoding conversions for 7.3 release.
--
Tatsuo Ishii
-
Tom Lane writes:
> That does not change my opinion about the -X/PGXLOG switch though ---
> having a backup safety check is not an excuse for having a fundamentally
> insecure set of startup options.
OK, so:
1. Leave -X option in initdb. Remove all other -X options.
2. Remove all uses of PGXLO
Tom Lane writes:
> > The prototype for fseek() is long int; I had assumed that off_t was not
> > defined if _LARGEFILE_SOURCE was not defined.
All that _LARGEFILE_SOURCE does is make fseeko() and ftello() visible on
some systems, but on some systems they should be available by default.
> Oh, yo
Tom Lane writes:
> * postmaster log to stderr --- does this fail if log output
> exceeds 2G?
That would be an issue of the shell, not the postmaster.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you
Sounds good to me, but I have proven very unreliable in guessing others
opinions on this issue.
---
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > That does not change my opinion about the -X/PGXLOG switch though ---
> >
On Wed, 2002-08-14 at 00:38, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Tue, 2002-08-13 at 22:38, Tom Lane wrote:
> >> It's still "extensible", it's just not so easily "contractible"...
> >>
> >> I'm not sure that this matters, as I've never heard of anyone actually
> >> t
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 13 August 2002 18:24
> To: Peter Eisentraut
> Cc: Marc G. Fournier; PostgreSQL Development
> Subject: Re: [HACKERS] libpqxx
>
>
> JDBC and ODBC are almost separate projects already, and
> perhaps should be cut
Hannu Krosing <[EMAIL PROTECTED]> writes:
> On Wed, 2002-08-14 at 00:38, Tom Lane wrote:
>> For an embedded system I'd think you'd want to strip out the support
>> code for the unwanted types (ie, the utils/adt/ file(s)), not only the
>> catalog entries.
> But if the types themselves were install
I have applied the attached patch which changes NAMEDATALEN to 64 and
FUNC_MAX_ARGS/INDEX_MAX_KEYS to 32. Hopefully this will keep people
happy for a few more years.
initdb required.
---
Christopher Kings-Lynne wrote:
> >
1 - 100 of 187 matches
Mail list logo
