Sergio Bruder <[EMAIL PROTECTED]> writes:
> I've found a corrupted document in PostgreSQL 7.1.2, more specificaly
> src/bin/pgaccess/doc/html/tutorial/copyright.html
Not only is it a mess now, but it seems it's always been a mess :-(.
None of the past CVS versions look very clean either.
Who's t
In order to be able to implement updateable result
sets there needs to be a mechanism for determining if the underlying data has
changed since the resultset was fetched. Short of retrieving the current data
and comparing the entire row, can anyone think of a way possibly using the row
versio
"Joe Conway" <[EMAIL PROTECTED]> writes:
>> Too late ;-). I just finished ripping out the unneeded parts and
>> applying.
> Thanks! I take it I still need to do the documentation though ;)
I put in a few words in func.sgml, but feel free to improve on it.
regards, tom l
"Joe Conway" <[EMAIL PROTECTED]> writes:
> I'll rework the patch per the above and resend.
Too late ;-). I just finished ripping out the unneeded parts and
applying.
I made a few minor changes too, mostly removing unnecessary code
(you don't need to call nameout, everyone else just uses NameStr
On Thu, Jun 14, 2001 at 12:23:22AM +, Thomas Lockhart wrote:
> > Surely the correct solution is to have a config file somewhere
> > that gets read on startup? That way us Australians don't have to be the only
> > ones in the world that need a custom built postgres.
>
> I will point out that "
Now that you've narrowed it down to a specific table, at least you can
specifically vacuum just that table and ignore the rest of the database
...might help a bit?
On Wed, 13 Jun 2001, Mike Cianflone wrote:
> After the comment by someone about the UPDATE being responsible for
> the reason
>> Attached is a patch adding following functions:
>>
>> inet(text), cidr(text): convert a text value into inet/cidr
>> set_masklen(inet): set masklen on the inet value
>>
>> Patch also contains regression checks for these functions.
How about some documentation updates to go with that?
Vince Vielhaber <[EMAIL PROTECTED]> writes:
>> Feel free to submit a grammar patch to make CREATE USER more flexible
>> about the ordering of its optional clauses. Right now it's pretty
>> rigid.
> Let me guess, gram.y?
Yup.
regards, tom lane
--
On Wed, 13 Jun 2001, Tom Lane wrote:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > mydb=# create user foo NOCREATEUSER NOCREATEDB in group bar;
> > ERROR: parser: parse error at or near "NOCREATEDB"
>
> > This line:
> > [ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ]
> > does s
After the comment by someone about the UPDATE being responsible for
the reason for vacuuming (sorry, I didn't know that), I looked into a stored
procedure that gets triggered during an insert. The stored procedure does an
UPDATE on another table, for every insert. So inserting 100,000 item
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> mydb=# create user foo NOCREATEUSER NOCREATEDB in group bar;
> ERROR: parser: parse error at or near "NOCREATEDB"
> This line:
> [ CREATEDB | NOCREATEDB ] [ CREATEUSER | NOCREATEUSER ]
> does say I can do both, right?
It says you can do both *
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Could we make the assumption that table names in catalogs
>> will be of type 'name'?
> I wouldn't want to guarantee it for the information schema.
Your objections are not without merit, and in the interest of bringing
this thing to closure I'll con
I know this topic was discussed a few months ago, but I'm wondering if any
decisions have been reached on if, how, and when setuid functions and triggers
might be implemented. If not, I have an idea to throw at it.
Thanks,
Mark
---(end of broadcast)---
According to \h create user I can stipulate NOCREATEDB and NOCREATEUSER
when I create a user. But I get this:
mydb=# create user foo NOCREATEUSER NOCREATEDB in group bar;
ERROR: parser: parse error at or near "NOCREATEDB"
mydb=#
I can create the user by only stipulating one of the NOCREATE it
Hello all,
I have PostgreSQL 7.1.1 installed on a RedHat 7.1 server.
When running the following query "SELECT Field1 || Field2 AS Result FROM Table"
the result is NULL when Field2 is NULL.
Same as if I use a PL/pgSQL function to concatenate Filed 1 || Field2.
Did I miss something?
Regards,
Je
> > - only full replication possible
> I do not understand that point, if it is trigger based, you
> have all the flexibility you need. (only some tables, only some rows,
> different rows to different targets ),
> (or do you mean not all targets, that could also be achieved with
triggers)
> The other question is, what are your startup parameters? What sort of
> shared memory buffer are you working with? I image that VACUUM does a
> flush to disk, so are 1000 items filling your buffer(s),
> causing an almost
> continue fsync to disk for each INSERT after that ... so the VACUUM is
> On Tue, 12 Jun 2001, Bruce Momjian wrote:
>> I am confused. I thought I fixed this about a month ago. Do we need
>> more coded added here?
You did, and we don't. In current sources:
regression=# SELECT pg_class FROM pg_class;
ERROR: You can't use relation names alone in the target list,
On Wed, 13 Jun 2001, mlw wrote:
> I was thinking this morning, how much work would it be to change the directory
> structure of Postgres.
Another useful change would be the addition of directory splitting in the
database directories. This will increase performance on operating systems
whose fil
> Well as I read back the thread I see 2 different approaches to
> replication:
>
> 1: tight integrated replication.
> pro:
> - bi-directional (or multidirectional): updates are possible everywhere
> - A cluster of servers allways has the same state.
> - it does not matter to which server you
8k ...
On Wed, 13 Jun 2001, Andy Samuel wrote:
> The same question ... how's the size after you vacuum the tables/db ?
>
> > continuous UPDATEs happening to his table, no INSERTs, no DELETEs ... and
> > his tables quicklky grow from a 8k table to 65Meg if there is no vacuum
> > happening every
The same question ... how's the size after you vacuum the tables/db ?
> continuous UPDATEs happening to his table, no INSERTs, no DELETEs ... and
> his tables quicklky grow from a 8k table to 65Meg if there is no vacuum
> happening every few *hours* ...
TIA
Andy
---(en
On Wed, 13 Jun 2001, Zeugswetter Andreas SB wrote:
>
> > Is there a relative consensus for how often to run vacuum? I have a
> > table of about 8 columns that I fill with 100,000 items simply via a "\i
> > alarms.sql". After 1,000 items or so it gets extremely slow to fill with
> > data, and
> Is there a relative consensus for how often to run vacuum? I have a
> table of about 8 columns that I fill with 100,000 items simply via a "\i
> alarms.sql". After 1,000 items or so it gets extremely slow to fill with
> data, and will take over a day to fill the entire thing unless I run
24 matches
Mail list logo
