Hi,
I'm playing around with the Full Text Indexing module, and I notice that
it's case-sensitive. This seems to be pretty useless to me - especially for
my application. I wonder if there'd be any objections to me modifying it to
be case-insensitive. Or at least be configurable either way...
A
At 11:25 18/07/01 +0900, Hiroshi Inoue wrote:
>
>Oops I made a mistake.
>Reference name is needed not an object name,
>i.e
> object relid
> object oid
> relerence relid
> reference oid
> reference name
>
I think any deisgn needs to cater for attr dependencies. eg.
> Then we have an pg_depend entry e.g.
>
> pg_class_relid
> oid of the view_a
> pg_class_relid
> oid of the table a
> 'a' the name of the table
>
> and so on.
>
> drop table a; (unadorned drop).
>
> Then the above entry would be changed to
>
> pg_class_rel
Bruce Momjian wrote:
>
> > I like
> > object relid
> > object oid
> > object name
> > reference relid
> > reference oid
>
> Can I ask why you like the object name?
>
Oops I made a mistake.
Reference name is needed not an object name,
i.e
object relid
As some of you know, Nusphere is trying to sell MySQL with an additional
transaction-based table manager called Gemini. They enabled download of
the source code yesterday at:
http://mysql.org/download3.php?file_id=1118
Looking through the 122k lines of C code in the Gemini directory, it
> I like
> object relid
> object oid
> object name
> reference relid
> reference oid
Can I ask why you like the object name?
>
> and unadorned DROP doesn't drop dependent objects.
OK.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL
Peter Eisentraut wrote:
>
> Bruce Momjian writes:
>
> > > That was me. The point, however, was, given object id 145928, how the
> > > heck to you know what table this comes from?
> >
> > I think we will need the relid of the system table. I imagine four
> > columns:
> >
> > object relid
>
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Christopher Kings-Lynne wrote:
> >> Just out of interest, is there a special reason it's difficult to implement
> >> the DEFAULT feature of alter table add column?
>
> > Without *DEFAULT* we don't have to touch the table file
> > a
On Tue, 17 Jul 2001, Tom Lane wrote:
> Bill Studenmund <[EMAIL PROTECTED]> writes:
> > I think it's actually O(N^M) where there are N system objects and a chain
> > of M dependencies (A depends on B which depends on C => M = 3).
>
> It's probably not *that* bad. It's reasonable to assume that o
Bill Studenmund <[EMAIL PROTECTED]> writes:
> I think it's actually O(N^M) where there are N system objects and a chain
> of M dependencies (A depends on B which depends on C => M = 3).
It's probably not *that* bad. It's reasonable to assume that only a
small number of objects actually depend di
On Tue, 17 Jul 2001, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > The alternative to pg_depend is to do a brute force scan of all the
> > system catalogs looking for dependent objects. In that case, you'd
> > know what you are looking at, but if we extract the dependencies as
> > a separate
On Tue, 17 Jul 2001, Tom Lane wrote:
> Seems like a bad idea; it'll slow down deletes quite a lot, no? Do you
> really want to (for example) parse every SQL function in the system to
> see if it refers to a table being dropped? Why would we want to do that
> work over again for every such delet
[EMAIL PROTECTED] (Frank Ch. Eigler) writes:
> Could you explain how postgresql can "fall victim" the filesystem hole
> mechanism? Just hoping to force actual storage allocation, or hoping
> to discourage fragmentation?
The former. We'd prefer not to get an unexpected "disk full" failure
while
Bruce Momjian wrote:
>
> Checking application/pgp-signature: FAILURE
> -- Start of PGP signed section.
> > Hi -
> >
> > pgman wrote:
> >
> > : Most Unix filesystems will not allocate disk blocks until you write in
> > : them. [...]
> >
> > Yes, I understand that, but how is it a problem for postg
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> The alternative to pg_depend is to do a brute force scan of all the
>> system catalogs looking for dependent objects. In that case, you'd
>> know what you are looking at, but if we extract the dependencies as
>> a separate table,
Patrick Macdonald <[EMAIL PROTECTED]> writes:
> Well, notion and actual practice can be mutually exclusive. Your
> initial message stated that you would like to rename the log segment.
> This insinuated that the log segment was not moved. Therefore, a
> straight rename would cause problems with
> Tom Lane writes:
>
> > The alternative to pg_depend is to do a brute force scan of all the
> > system catalogs looking for dependent objects. In that case, you'd
> > know what you are looking at, but if we extract the dependencies as
> > a separate table, I don't see how you'd know without bei
Hi Hackers,
One of the biggest gaps I've found while doing performance tuning is
collecting execution statistics. There's EXPLAIN for the planner, but
nothing for the executor. Maybe another verb; ACCOUNT?
I'm not suggesting this as work that someone else do. I don't mind
trying it myself, but
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Hi -
>
> pgman wrote:
>
> : Most Unix filesystems will not allocate disk blocks until you write in
> : them. [...]
>
> Yes, I understand that, but how is it a problem for postgresql?
Uh, I thought we did that so we
Tom Lane writes:
> The alternative to pg_depend is to do a brute force scan of all the
> system catalogs looking for dependent objects. In that case, you'd
> know what you are looking at, but if we extract the dependencies as
> a separate table, I don't see how you'd know without being told.
Th
Patrick Macdonald <[EMAIL PROTECTED]> writes:
> I understand your solution is for the existing architecture which does
> not support point-in-time recovery. If this item is picked up, your
> solution will become a stumbling block due the above mentioned log
> extent deletions.
Hmm, I don't see w
> Could you explain how postgresql can "fall victim" the filesystem hole
> mechanism? Just hoping to force actual storage allocation, or hoping
> to discourage fragmentation?
Most Unix filesystems will not allocate disk blocks until you write in
them. If you just seek out past end-of-file, the
> When you drop a table, there are only so many things that could depend on
> it:
>
> * rules/views
> * triggers
> * check constraints
> * foreign key constraints
> * primary key constraints
> * unique constraints
> * subtables
>
> including their dependencies. There might be others I forgot bu
>> I am pumping about 200gb a week through the pg database,
>> and our estimated database size is something like 4tb by
>> the end of the year.
>
> Can anyone say 'Woof!'?
Amen, Lamar. I was trying to think of something myself besides
'Wow!'...
As a side note, there's a blurb in the July 16, 20
Bruce Momjian writes:
> Is it? Are we going to record dependency both ways, e.g primary table
> -> foreign table and foreign table -> primary table, or just one of
> them. And when we see we depend on something, do we know always what it
> could be. If I drop a table and I depend on oid XXX, d
tgl wrote:
: [...] (We have to physically fill each segment with zeroes to
: ensure that the system has actually allocated a whole 16MB to it;
: otherwise we fall victim to the "hole-saving" allocation technique
: of most Unix filesystems.) [...]
Could you explain how postgresql can "fall vic
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> But how then do you find the system table that uses the given oid?
> It's implied by the column you're looking at.
It is? Remember that we need to use this table to get from an object
to the objects that depend on it. A da
[EMAIL PROTECTED] writes:
> I have written a postgres C function that
> uses a popen linux system call. Orginally when I first tried it I kept
> getting an ECHILD. I read a little bit more on the pclose function
> and the wait system calls and discoverd that on LINUX if the signal
> handler for
Tom Lane writes:
> Besides, it seems to me there are cases where you don't really
> *want* the DEFAULT value to be used to fill the column, but something
> else (or even want NULLs).
Then you could use
ALTER TABLE t1 ADD COLUMN cn text;
ALTER TABLE t1 ALTER COLUMN cn SET DEFAULT 'what you reall
> When a table is dropped, you scan all of these objects (their system
> catalogs) for matches against the table and either do a cascade or
> restrict. This is not new, we already do this for indexes and
> descriptions, for instance.
I was thinking we could centralize all that checking in pg_dep
> I have noticed that a large fraction of the I/O done by 7.1 is
> associated with initializing new segments of the WAL log for use.
> (We have to physically fill each segment with zeroes to ensure that
> the system has actually allocated a whole 16MB to it; otherwise we
> fall victim to the "hole
> Bruce Momjian writes:
>
> > > I'm not seeing the point. You're essentially duplicating the information
> > > that's already available in the system catalogs. This is bound to become
> > > a catastrophe the minute a user steps in and does manual surgery on some
> > > catalog. (And yes, manual
On Monday 16 July 2001 14:48, alex avriette wrote:
> Our hardware is a cluster of 3 ultra 10's, a pair of 700-dvd jukeboxes
> (with burners), a 2.5tb SAN, 10 DAT tape readers, a pair of dvd-roms, and 2
> 200gb disk packs (one for each of our tape-reading suns -- the other one
> manages the DVD juk
"Dominic J. Eidson" <[EMAIL PROTECTED]> writes:
> On Tue, 17 Jul 2001, Philip Warner wrote:
> Any ideas what would cause this?
>>
>> Probably the length of the view name; which version are you running? I
>> haven't look at PG for a while, but I thought this was fixed in 7.1.2
> PostgreSQL 7.1 o
I have noticed that a large fraction of the I/O done by 7.1 is
associated with initializing new segments of the WAL log for use.
(We have to physically fill each segment with zeroes to ensure that
the system has actually allocated a whole 16MB to it; otherwise we
fall victim to the "hole-saving" a
Bruce Momjian writes:
> > I'm not seeing the point. You're essentially duplicating the information
> > that's already available in the system catalogs. This is bound to become
> > a catastrophe the minute a user steps in and does manual surgery on some
> > catalog. (And yes, manual surgery sho
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> Just out of interest, is there a special reason it's difficult to implement
>> the DEFAULT feature of alter table add column?
> Without *DEFAULT* we don't have to touch the table file
> at all. With *DEFAULT* we have to
> Bruce Momjian writes:
>
> > > That was me. The point, however, was, given object id 145928, how the
> > > heck to you know what table this comes from?
> >
> > I think we will need the relid of the system table. I imagine four
> > columns:
> >
> > object relid
> > object oid
> > re
I was wondering if some of you Postgres hackers could advise me on the
safety of the following. I have written a postgres C function that
uses a popen linux system call. Orginally when I first tried it I kept
getting an ECHILD. I read a little bit more on the pclose function
and the wait system
On Tue, 17 Jul 2001, Philip Warner wrote:
> At 22:12 16/07/01 -0500, Dominic J. Eidson wrote:
> >morannon:~>pg_dump -t bboard openacs | less
> >getTables(): SELECT (for VIEW ec_subsubcategories_augmented) returned NULL
> oid
> >SELECT was: SELECT definition as viewdef, (select oid from pg_rewrite
Hello
I know that exists a script file for postgreSQL that have the operator *=
and others.
Where can I find that script ?
Thanks
Luis Sousa
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lo
Bruce Momjian writes:
> > That was me. The point, however, was, given object id 145928, how the
> > heck to you know what table this comes from?
>
> I think we will need the relid of the system table. I imagine four
> columns:
>
> object relid
> object oid
> reference relid
>
On Thu, Jul 12, 2001 at 11:08:34PM +0200, Peter Eisentraut wrote:
> Nathan Myers writes:
>
> > When the system is too heavily loaded (however measured), any further
> > login attempts will fail. What I suggested is, instead of the
> > postmaster accept()ing the connection, why not leave the conn
On Tuesday, 10. July 2001 11:45, you wrote:
> > When a new table or field is created without quotes, it is assumed to be
> > case-insensitive. Herefore I have some questions:
> >
> > - Is it SQL-92-conform to handle >"test"< like >test< without quotes, or
> > shouldn't it be >test< forced to lower
Title: RE: [HACKERS] JDBC Support - prepared Statements?
The release postgresql-jdbc-7.1.2-4PGDG.i386.rpm is definately buggy. Or at least there has been a confusion with versioning. I have a had a number of small issues, but when I downloaded the source and compiled the JDBC drivers through
I've done some searching through the mailing lists and haven't found
any info regarding what I need.
I have an array of values of type int8.
I want to be able to rollup the data and have postgres do all the
summing for me. I've looked at the commands and haven't found what I
need.
Here is wh
46 matches
Mail list logo
