> I believe that it is appropriate for contrib/ because it is a good demo
> of FTI-like capabilities. But nothing more, yet. For at least a couple
> of reasons:
>
> 1) It generates the "index" as a table, not a PostgreSQL index or
> index-like thing.
>
> 2) It has a hardcoded list of non-indexed
> > OK, can someone collect suggestions, add the code, and integrate it for
> > 7.1?
>
> too late in cycle ...
How about first thing for 7.2 then? While it lies in limbo,
its never going to get the attention it deserves.
Regards
> (the second one fails). Now that I look, this breakage was introduced in
> March when "we" expunged operators allowed as identifiers (Tom Lane and
> I have blood on our hands on this one ;) See gram.y around line 5409.
> Suggestions?
Any problems with allowing OVERLAPS and BETWEEN as function n
On Mon, 27 Nov 2000, mlw wrote:
> This is just a curiosity.
>
> Why is the default postgres block size 8192? These days, with caching
> file systems, high speed DMA disks, hundreds of megabytes of RAM, maybe
> even gigabytes. Surely, 8K is inefficient.
I think it is a pretty wild assumption
> At 14:11 28/11/00 +0800, Christopher Kings-Lynne wrote:
> >Hi,
> >
> >Does anyone have a snippet of postgres SQL that will create a database with
> >_everything_ that postgres supports? (ie. types, functions, constraints,
> >operators, everything...)
>
> I tend to use my own databases (because
[ Charset ISO-8859-1 unsupported, converting... ]
> I modified the FTI trigger for my own use a while ago (indexes whole
> words, eliminates duplicate a few other things) -- I'm not sure if it would
> do anyone any good but you're welcome to it. To whom should I send it?
Is full-word optional
> At 09:30 PM 11/27/00 -0500, Bruce Momjian wrote:
>
> >> Well, true, but when you have 256 MB or a half-gig or more to devote to
> >> the cache, you get plenty of blocks, and in pre-PG 7.1 the 8KB limit is a
> >> pain for a lot of folks.
> >
> >Agreed. The other problem is that most people have
At 14:11 28/11/00 +0800, Christopher Kings-Lynne wrote:
>Hi,
>
>Does anyone have a snippet of postgres SQL that will create a database with
>_everything_ that postgres supports? (ie. types, functions, constraints,
>operators, everything...)
I tend to use my own databases (because the have lots o
> As for the treading-on-user-namespace issue, we already do that for all
> implicitly created indexes (see UNIQUE, PRIMARY KEY, etc). I'd prefer
> to treat named constraints consistently with that long-established
> practice until we have a better idea that can be implemented uniformly
> across
Hi,
Does anyone have a snippet of postgres SQL that will create a database with
_everything_ that postgres supports? (ie. types, functions, constraints,
operators, everything...)
I just need it for testing SQL dump code.
If not, then I'll create one myself and post it back here.
Thanks,
Chri
> > > Maybe asking 'Why isn't the contrib full-text-indexer not in the main
> > > tree?' would be more productive on that front.
> > Well, yes. Why isn't it?
I believe that it is appropriate for contrib/ because it is a good demo
of FTI-like capabilities. But nothing more, yet. For at least a cou
Philip Warner <[EMAIL PROTECTED]> writes:
>>> Is there a good reason why the automatically created items do not have a
>>> 'pg_' in front of their names?
>>
>> Not a good idea. I think it should probably be pk1_zzz in this case.
> That would at least be consistent, but it's still using 'user na
At 11:06 PM 11/27/00 -0400, The Hermit Hacker wrote:
>On Mon, 27 Nov 2000, Bruce Momjian wrote:
>> OK, can someone collect suggestions, add the code, and integrate it for
>> 7.1?
>
>too late in cycle ...
Yes...
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, Pa
At 00:24 28/11/00 -0500, Tom Lane wrote:
>Philip Warner <[EMAIL PROTECTED]> writes:
>> Just noticed this:
>
>> pjw=# create table pk1(f1 integer, constraint zzz primary key(f1));
>> NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'zzz' for
>> table 'pk1'
>> CREATE
>> pjw=# create tabl
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I don't believe it's a performance issue, I believe it's that writes to
> blocks greater than 8k cannot be guaranteed 'atomic' by the operating
> system. Hence, 32k blocks would break the transactions system.
As Nathan remarks nearby, it's
Philip Warner <[EMAIL PROTECTED]> writes:
> Just noticed this:
> pjw=# create table pk1(f1 integer, constraint zzz primary key(f1));
> NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'zzz' for
> table 'pk1'
> CREATE
> pjw=# create table zzz(f1 integer);
> ERROR: Relation 'zzz' alrea
I modified the FTI trigger for my own use a while ago (indexes whole
words, eliminates duplicate a few other things) -- I'm not sure if it would
do anyone any good but you're welcome to it. To whom should I send it?
-Mitch
- Original Message -
From: "The Hermit Hacker" <[EMAIL PROTEC
[EMAIL PROTECTED] writes:
> Tom Lane wrote:
>> Do you have any problem with releasing your stuff under the Postgres
>> distribution terms (BSD license)?
> No, I don't see any problem with the BSD license, or any other
> license, for that matter. I just had some reservations about releasing
> stuf
On Tue, 28 Nov 2000, John Huttley wrote:
> 3. Stored Procedures returning a record set.
>
> Dream on!
This is something I would be really interested to see working. What are the
issues? my understanding is that it is technically feasible but too
complicated to add to PL/PGsql? it seems to me
On Mon, 27 Nov 2000, Bruce Momjian wrote:
> > >Well, yes. Why isn't it?
> > >
> > >Full text indexing should be just as much a feature as any other key feature in
> > >PG.
> > >With the advent of unlimited file and record lengths in 7.1, this would be a good
> > >time to
> > >include it.
> > >
>
At 09:30 PM 11/27/00 -0500, Bruce Momjian wrote:
>> Well, true, but when you have 256 MB or a half-gig or more to devote to
>> the cache, you get plenty of blocks, and in pre-PG 7.1 the 8KB limit is a
>> pain for a lot of folks.
>
>Agreed. The other problem is that most people have 2-4MB of cach
> >Well, yes. Why isn't it?
> >
> >Full text indexing should be just as much a feature as any other key feature in
> >PG.
> >With the advent of unlimited file and record lengths in 7.1, this would be a good
> >time to
> >include it.
> >
> >FTI is particularly useful in the context of web content e
John Huttley wrote:
> > Maybe asking 'Why isn't the contrib full-text-indexer not in the main
> > tree?' would be more productive on that front.
> Well, yes. Why isn't it?
I'm hoping to see the answer to that one myself, as that is outside my
scope currently. I just RPMize things... Although,
> At 08:39 PM 11/27/00 -0500, Bruce Momjian wrote:
> >[ Charset ISO-8859-1 unsupported, converting... ]
> >> If it breaks anything in PostgreSQL I sure haven't seen any evidence -- the
> >> box this database is running on gets hit pretty hard and I haven't had a
> >> single ounce of trouble since
At 08:39 PM 11/27/00 -0500, Bruce Momjian wrote:
>[ Charset ISO-8859-1 unsupported, converting... ]
>> If it breaks anything in PostgreSQL I sure haven't seen any evidence -- the
>> box this database is running on gets hit pretty hard and I haven't had a
>> single ounce of trouble since I went to
At 02:51 PM 11/28/00 +1300, John Huttley wrote:
>>
>> Maybe asking 'Why isn't the contrib full-text-indexer not in the main
>> tree?' would be more productive on that front.
>
>Well, yes. Why isn't it?
>
>Full text indexing should be just as much a feature as any other key feature in
>PG.
>With th
On Mon, Nov 27, 2000 at 06:03:33PM -0600, [EMAIL PROTECTED] wrote:
> Franck Martin wrote:
> > I suppose your code is under GPL, and you have no problem for me to
> > use it, providing I put your name and credits somewhere.
>
> No problem at all -- I will be honored if you use it. Was I careless
>
>
> Maybe asking 'Why isn't the contrib full-text-indexer not in the main
> tree?' would be more productive on that front.
Well, yes. Why isn't it?
Full text indexing should be just as much a feature as any other key feature in
PG.
With the advent of unlimited file and record lengths in 7.1, thi
Nothing is guaranteed for anything larger than 512 bytes, and even
then you have maybe 1e-13 likelihood of a badly-written block written
during a power outage going unnoticed. (That is why the FAQ recommends
you invest in a UPS.) If PG crashes, you're covered, regardless of
block size. If t
[ Charset ISO-8859-1 unsupported, converting... ]
> If it breaks anything in PostgreSQL I sure haven't seen any evidence -- the
> box this database is running on gets hit pretty hard and I haven't had a
> single ounce of trouble since I went to 7.0.X
Larger block sizes mean larger blocks in the c
If it breaks anything in PostgreSQL I sure haven't seen any evidence -- the
box this database is running on gets hit pretty hard and I haven't had a
single ounce of trouble since I went to 7.0.X
-Mitch
- Original Message -
From: "Christopher Kings-Lynne" <[EMAIL PROTECTED]>
To: "Hackers
John Huttley wrote:
> Would you please consider bringing the contributed package into the
> official distribution.
> I found that trying to compile it with the RedHat RPM based installation
> was a monumental pain. I gave up.
> Its useful, people ask about it on the list, so why not?
If there
I don't believe it's a performance issue, I believe it's that writes to
blocks greater than 8k cannot be guaranteed 'atomic' by the operating
system. Hence, 32k blocks would break the transactions system. (Or
something like that - am I correct?)
Chris
> -Original Message-
> From: [EMAI
Would you please consider bringing the contributed package into the
official distribution.
I found that trying to compile it with the RedHat RPM based installation
was a monumental pain. I gave up.
Its useful, people ask about it on the list, so why not?
For comparison, checkout what MSSQL 7 c
Thanks for your help, everyone.
This is a summary of replies.
1. Calculated fields in table definitions . eg.
Create table test (
A Integer,
B integer,
the_sum As (A+B),
);
This functionality can be achieved through the use of views.
Implementing th
Tom Lane wrote:
> Do you have any problem with releasing your stuff under the Postgres
> distribution terms (BSD license)?
No, I don't see any problem with the BSD license, or any other
license, for that matter. I just had some reservations about releasing
stuff that was far from perfect, and it
Franck Martin wrote:
> I have already created geographical objects which contains MBR(Minimum
> Bounding Rectangle) in their structure, so it is a question of rewriting
> your code to change the access to the cube structure to the MBR structure
> inside my geoobject. (cf http://fmaps.sourceforge.n
I've been using a 32k BLCKSZ for months now without any trouble, though I've
not benchmarked it to see if it's any faster than one with a BLCKSZ of 8k..
-Mitch
> This is just a curiosity.
>
> Why is the default postgres block size 8192? These days, with caching
> file systems, high speed DMA dis
proc.c has the following code --- unchanged since Postgres95 ---
in HandleDeadlock():
/* -
* Check to see if we've been awoken by anyone in the interim.
*
* If we have we can return and resume our transaction -- happy day.
* Before we are awoken the pro
Philip Warner writes:
> pjw=# create table pk1(f1 integer, constraint zzz primary key(f1));
> NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'zzz' for
> table 'pk1'
> CREATE
> pjw=# create table zzz(f1 integer);
> ERROR: Relation 'zzz' already exists
>
> Is there a good reason why
This is just a curiosity.
Why is the default postgres block size 8192? These days, with caching
file systems, high speed DMA disks, hundreds of megabytes of RAM, maybe
even gigabytes. Surely, 8K is inefficient.
Has anyone done any tests to see if a default 32K block would provide a
better overal
Just noticed this:
pjw=# create table pk1(f1 integer, constraint zzz primary key(f1));
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'zzz' for
table 'pk1'
CREATE
pjw=# create table zzz(f1 integer);
ERROR: Relation 'zzz' already exists
Is there a good reason why the automatically
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't like the code in fe-connect.c one bit, it's way messed up.
Yes. We've accepted several extremely questionable (not to mention
poorly documented or completely undocumented) "features" in there
recently. If I'd been paying more attention I
Cyril VELTER <[EMAIL PROTECTED]> writes:
> Unfortunatly, there is no hard link on beos :=(. link and unlink are
> there, but link always return "No such file or directory".
Somewhere right around here is where I am going to ask why we are
entertaining the idea of a BeOS port in the first pla
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Am I handling this properly? I hate to be dragging around the unix
> > socket directory name in pghost for too long and hate to be propogating
> > the slash test throughout the code.
>
> It's probably cleanest to do that the way you are doing it.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Am I handling this properly? I hate to be dragging around the unix
> socket directory name in pghost for too long and hate to be propogating
> the slash test throughout the code.
It's probably cleanest to do that the way you are doing it. However,
one
Well, actually, unixsocket can be specified by PQconnectdb. Sounds like
it is a big mess. Care to tame it? I am heading to Japan tomorrow and
don't want to leave it 1/2 done.
> Bruce Momjian writes:
>
> > Am I handling this properly? I hate to be dragging around the unix
> > socket director
Bruce Momjian writes:
> Am I handling this properly? I hate to be dragging around the unix
> socket directory name in pghost for too long and hate to be propogating
> the slash test throughout the code.
ISTM that you could just do this in connectDBStart() where it actually
decides on AF_UNIX.
Unfortunatly, there is no hard link on beos :=(. link and unlink are
there, but link always return "No such file or directory".
BTW, What the code in XLogFileInit is supposed to do ? Why not create the
file with the right name in the first step ?
I have tried to create the file w
Hi all,
I heard there is a patch which can assign encoding other the database
default. Can anyone tell me where to get it, or where can I get more
information.
Thanks
Dave
> Bruce Momjian writes:
>
> > Done. I did not change PQunixsocket or the unixsocket PQconnectdb
> > connection option. Should they be changed too?
>
> They should be removed because PQhost does this now.
I assume you mean PQunixsocket. As part of the database connection, if
pghost begins wit
[EMAIL PROTECTED] writes:
> Tom Lane wrote:
>> Michael Ansley <[EMAIL PROTECTED]> writes:
Remember also that the GiST library has been integrated into PG, (my brother
is doing some thesis workon that at the moment),
>>
>> Yeah? Does it still work?
> You bet. One would otherwise be hea
On Mon, 27 Nov 2000, Don Baccus wrote:
> >Actually, they aren't the same at all under Oracle or under Postgres.
> >
> >A null represents a lack of data, whereas an empty string is represents
> >data of zero length and zero content. Null is a state and not a value.
>
> Unfortunately Mario's entir
At 12:44 PM 11/27/00 -0500, Tom Lane wrote:
>Mario Weilguni <[EMAIL PROTECTED]> writes:
>> In Oracle, empty strings and null are basicly the same,
>
>Are you sure about that? It'd be a pretty major failure to comply with
>SQL standard semantics, if so.
Thought you'd get a kick out of this:
Conn
At 06:09 PM 11/27/00 +0100, Mario Weilguni wrote:
>Sorry if I'm posting to the wrong list, but I don't know which list is
>appropriate for this question.
>
>I've a question concerning compatibilty Postgres <-> Oracle. In Oracle,
empty
>strings and null are basicly the same, but it does not seem
At 12:39 PM 11/27/00 -0500, Alex Perel wrote:
>On Mon, 27 Nov 2000, Mario Weilguni wrote:
>
>> Sorry if I'm posting to the wrong list, but I don't know which list is
>> appropriate for this question.
>>
>> I've a question concerning compatibilty Postgres <-> Oracle. In Oracle,
>> empty strings
At 10:46 AM 11/27/00 -0600, Ross J. Reedstrom wrote:
>Uh, Don?
>Not all the world's a web page, you know. Thatkind of thinking is _so_
>mid 90's ;-) Dedicated apps that talk directly the user seem to be making
>a comeback, due to a number of factors. They can have much cleaner user
>interfaces, f
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Lamar Owen writes:
> >> Ok, let me repeat -- the '--enable-locale' setting will not affect the
> >> collation sequence problem on RedHat. If you set PostgreSQL to use
> >> locale, it uses it. If you configure PostgreSQL to not us
Tom Lane wrote:
> Michael Ansley <[EMAIL PROTECTED]> writes:
> > Remember also that the GiST library has been integrated into PG, (my brother
> > is doing some thesis workon that at the moment),
>
> Yeah? Does it still work?
You bet. One would otherwise be hearing from me. I depend on it quite
> > Thomas Lockhart would be the authority on this, but my impression is
> > that tinterval is deprecated and will eventually go away in favor of
> > the SQL-standard interval type. If you've found functions that exist
> > for tinterval and not for interval, then that's an item for the TODO
> > l
On Mon, Nov 27, 2000 at 12:09:00PM -0500, Tom Lane wrote:
>
> I'm still not following exactly what people think would happen if we did
> have such a "feature". OK, the backend times out after some interval
> of seeing no activity, and disconnects. How is the client going to
> react to that, exa
On Mon, 27 Nov 2000, Mario Weilguni wrote:
> Sorry if I'm posting to the wrong list, but I don't know which list is
> appropriate for this question.
>
> I've a question concerning compatibilty Postgres <-> Oracle. In Oracle,
> empty strings and null are basicly the same, but it does not seem t
Mario Weilguni <[EMAIL PROTECTED]> writes:
> In Oracle, empty strings and null are basicly the same,
Are you sure about that? It'd be a pretty major failure to comply with
SQL standard semantics, if so.
SQL92 3.1 (Definitions):
null value (null): A special value, or mark, that is u
Sorry if I'm posting to the wrong list, but I don't know which list is
appropriate for this question.
I've a question concerning compatibilty Postgres <-> Oracle. In Oracle, empty
strings and null are basicly the same, but it does not seem to be under
Postgres, making migration a pain.
Exampl
On Mon, Nov 27, 2000 at 11:05:40AM -0500, Tom Lane wrote:
> Marko Kreen <[EMAIL PROTECTED]> writes:
> >> Well, we've talked before about moving the socket files to someplace
> >> safer than /tmp. The problem is to find another place that's not
> >> platform-dependent --- else you've got a major c
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> Which brings us back around to the point of why this is on Hackers:
> PostgreSQL currently has no clean method for dropping idle connections.
> Yes, some apps handle this themselves, but not all. A number of people
> seem to feel there is a need fo
Uh, Don?
Not all the world's a web page, you know. Thatkind of thinking is _so_
mid 90's ;-) Dedicated apps that talk directly the user seem to be making
a comeback, due to a number of factors. They can have much cleaner user
interfaces, for example.
Which brings us back around to the point of w
[ Charset ISO-8859-1 unsupported, converting... ]
>
> > > At 17:16 19/11/00 -0500, Tom Lane wrote:
> > >>
> > http://www.postgresql.org/cgi/cvsweb.cgi/pgsql/src/backend/utils/fmgr/README
> >
>
> Yes, this is now an imho very much improved way to go :-)
>
> I would probably have used the "para
Marko Kreen <[EMAIL PROTECTED]> writes:
>> Well, we've talked before about moving the socket files to someplace
>> safer than /tmp. The problem is to find another place that's not
>> platform-dependent --- else you've got a major configuration headache.
> Could this be described in e.g. /etc/pos
At 12:38 AM 11/27/00 -0700, Ron Chmara wrote:
>Don Baccus wrote:
>> At 12:07 AM 11/26/00 -0500, Alain Toussaint wrote:
>> >how about having a middle man between apache (or aolserver or any other
>> >clients...) and PosgreSQL ??
>> >that middleman could be configured to have 16 persistant connectio
Jan Wieck wrote:
> Hi,
>
> I'd like make some changes on the 7.1 (to be) libpgtcl.
>
> 1. Make the large object access null-byte safe, when
> libpgtcl is compiled against a 8.0 or higher version of
> Tcl.
>
> This would cause that a libpgtcl.so built
On Sat, Nov 25, 2000 at 07:41:52PM -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Actually, this turns out to be similar to what you wrote in
> > http://www.postgresql.org/mhonarc/pgsql-hackers/1998-08/msg00835.html
>
> Well, we've talked before about moving the socket
Title: RE: [HACKERS] Indexing for geographic objects?
To be honest, Tom, I've always seen GiST not just as a great feature, but as an essential feature. Using Stonebraker's definition of an object-relational database (which I tend to do, as it's the only one that I've read about in depth), w
Hi,
...
> LC_NUMERIC and LC_TIME
...
> The timeofday() make output via strftime() if you set LC_ALL, a query
> like: select timeofday()::timestamp;
Actually *I would* expect it to return a localized string. But then again I
always expect BE to use '.' as decimal point ( I must be damaged :-/ ).
> > At 17:16 19/11/00 -0500, Tom Lane wrote:
> >>
> http://www.postgresql.org/cgi/cvsweb.cgi/pgsql/src/backend/utils/fmgr/README
>
Yes, this is now an imho very much improved way to go :-)
I would probably have used the "parameter style" extension to create function,
but that is imho not an i
On Fri, 24 Nov 2000, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> I propose, therefore, that in an --enable-locale installation, initdb
> >> should save its values for LC_COLLATE and LC_CTYPE in pg_control, and
> >> backend startup should restore these
Franck Martin wrote:
>
> It seems that your code is exactly what I want.
>
> I have already created geographical objects which contains MBR(Minimum
> Bounding Rectangle) in their structure, so it is a question of rewriting
> your code to change the access to the cube structure to the MBR structu
77 matches
Mail list logo
