Tom Lane writes:
> Besides, it's a tad odd to see files that are marked group writable but
> not owner writable. You've got to agree there's not much sense in that.
How else are you going to commit files? /usr/bin/cvs is not setuid, so
the only way you can write to these files is being in the g
Is there demand for this syntax:
ALTER SEQUENCE ON table(col) CYCLE 100;
It would allow us to become sequence-name independent...
The above is an operation that would not help me a lot, but a way of
performing currval() without knowing the sequence name would be good.
It will help in cases suc
On Mon, 24 Nov 2003, Christopher Kings-Lynne wrote:
> Is there demand for this syntax:
>
> ALTER SEQUENCE ON table(col) CYCLE 100;
>
> It would allow us to become sequence-name independent...
The above is an operation that would not help me a lot, but a way of
performing currval() without know
Hi,
Is there demand for this syntax:
ALTER SEQUENCE ON table(col) CYCLE 100;
It would allow us to become sequence-name independent...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sun, 23 Nov 2003, Tom Lane wrote:
>> Sure, but couldn't we automatically turn off the write bits?
> Just curious, but what do the write bits harm?
They're just extra protection against making a dumb mistake; the old
belt-AND-suspenders theory.
On Sun, 23 Nov 2003, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Christopher Kings-Lynne wrote:
> >> You could consider adding a script to CVSROOT module to fix permissions
> >> upon commit?
>
> > Some files need execute bits, like perl scripts.
>
> Sure, but couldn't we automa
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> FK, primary, and unique constraints are already split out from the
> CREATE TABLE for performance reasons. We could think about folding them
> back in in a schema-only dump, but in a full dump I don't think it's
> negotiable --- you really want to load the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> You could consider adding a script to CVSROOT module to fix permissions
>> upon commit?
> Some files need execute bits, like perl scripts.
Sure, but couldn't we automatically turn off the write bits?
Christopher Kings-Lynne wrote:
> > The other things that are executable look like they legitimately are
> > scripts.
> >
> > If we consider that group-writability is bad (which ISTM we ought to)
> > then there are a *ton* of files with the wrong permissions. I'd
> > recommend getting Marc to fix
The other things that are executable look like they legitimately are
scripts.
If we consider that group-writability is bad (which ISTM we ought to)
then there are a *ton* of files with the wrong permissions. I'd
recommend getting Marc to fix it instead of hacking about with a
one-file-at-a-time me
Verifying zero rows in the freshly created table should be quite fast...
It's hundreds of times faster to add an index to a full table than add
rows to a table with an index.
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at onc
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
AFAICS mkdatadir() shouldn't consider subdir == NULL as a reason to
fail rather than trying mkdir_p.
Right. In fact, I can't see any good reason to call mkdir and then
mkdir_p at all. See my patch from
On Mon, 24 Nov 2003 11:41 am, Bruce Momjian wrote:
> > find pgsql-server/ -type f -perm +0333 -ls
>
> That command doesn't seem to work for me. I see:
I think that should be -perm +0111:
from man find:
-perm +mode
Any of the permission bits mode are set for the file.
This would fin
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> BTW, I can see a whole lot of files with the executable bit:
>>
>> find pgsql-server/ -type f -perm +0333 -ls
> That command doesn't seem to work for me.
He's looking for *either* write or execute permissions. AFAIK there is
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Um. Can anyone else check into those files now?
> Yes, I think so. The file used to be owned by Peter, but now by me:
Oh, okay. I had the idea they should all be owned by the cvs daemon,
but I guess that's not required.
>
Alvaro Herrera wrote:
> On Sun, Nov 23, 2003 at 06:59:45PM -0500, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Sure. I logged into the main server machine and cd'ed to CVSROOT. I
> > > then when to the src/bin/initdb directory, and because I didn't have
> > > permisssions,
On Sun, Nov 23, 2003 at 06:59:45PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Sure. I logged into the main server machine and cd'ed to CVSROOT. I
> > then when to the src/bin/initdb directory, and because I didn't have
> > permisssions, I moved initdb.c,v to another fi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Sure. I logged into the main server machine and cd'ed to CVSROOT. I
> > then when to the src/bin/initdb directory, and because I didn't have
> > permisssions, I moved initdb.c,v to another file name then copied it to
> > the original
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> AFAICS mkdatadir() shouldn't consider subdir == NULL as a reason to
>> fail rather than trying mkdir_p.
> Right. In fact, I can't see any good reason to call mkdir and then
> mkdir_p at all. See my patch from this afternoon.
I'm uns
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Sure. I logged into the main server machine and cd'ed to CVSROOT. I
> then when to the src/bin/initdb directory, and because I didn't have
> permisssions, I moved initdb.c,v to another file name then copied it to
> the original name so I owned the file.
Peter Eisentraut wrote:
> While people add more executable files to CVS (cf. initdb.c), can we do
> something about it?
Sure. I logged into the main server machine and cd'ed to CVSROOT. I
then when to the src/bin/initdb directory, and because I didn't have
permisssions, I moved initdb.c,v to ano
Tom Lane wrote:
AFAICS mkdatadir() shouldn't consider subdir == NULL as a reason to
fail rather than trying mkdir_p. Indeed, if anything the opposite:
when subdir isn't NULL the immediately prior directory level should
exist already.
Right. In fact, I can't see any good reason to call mkdir and
While people add more executable files to CVS (cf. initdb.c), can we do
something about it?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
Rod Taylor <[EMAIL PROTECTED]> writes:
Well.. the second one will be much slower when the foreign keys verify.
Primary, unique constraints I'll buy in the create statement. Check
constraints and defaults are a little fuzzier.
FK, primary, and unique constraints are already
On Sun, 23 Nov 2003, Tom Lane wrote:
> I see absolutely no need for the call path to do anything with this
> stuff before it reaches the language handler. All the handlers fetch
> the pg_proc tuple anyway
Even better then!
I've not gotten so far that i've looked much at that code. What I have
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> creating directory pg-install/var/data ... initdb: failed
> I will check it out. I know I spent quite some time making sure this
> worked, but I might have missed something obvious. I wonder if it is
> platform specific?
AF
Andrew Dunstan wrote:
Peter Eisentraut wrote:
Here is what I get:
peter ~$ pg-install/bin/initdb pg-install/var/data
...
creating directory pg-install/var/data ... initdb: failed
No points for details in the error message here either.
If I create pg-install/var first, then it work.
I will
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Is it easy to do a quick message change to state that it was the IPv6
> socket that failed?
I deliberately did not do that because we were well past error message
freeze for 7.4, but we certainly should fix it for 7.5.
regar
On Sun, 23 Nov 2003, Tom Lane wrote:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
> > On Sat, Nov 22, 2003 at 11:32:18PM -0400, Marc G. Fournier wrote:
> >> I suspect it might be because I'm running in a jail'd environment, but
> >> what should I be looking at to confirm?
> >>
> >> could not create s
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> And the cost will be fairly large for named parameters as well then. On
> the other hand, if one omits the parameter names one would get almost the
> same speed as before (an extra test is needed to see if we have any
> parameter names that needs to
Peter Eisentraut wrote:
Here is what I get:
peter ~$ pg-install/bin/initdb pg-install/var/data
...
creating directory pg-install/var/data ... initdb: failed
No points for details in the error message here either.
If I create pg-install/var first, then it work.
I will check it out. I know I sp
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> Is the reason to use name at all in pg "just" about speed, or is there
> some other reason?
Peter already explained it: we like fixed-width fields in system
catalogs so that we can overlay C struct definitions onto the tuples.
This is a fairly signifi
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Sat, Nov 22, 2003 at 11:32:18PM -0400, Marc G. Fournier wrote:
>> I suspect it might be because I'm running in a jail'd environment, but
>> what should I be looking at to confirm?
>>
>> could not create socket for statistics collector: Protocol not supp
Rod Taylor <[EMAIL PROTECTED]> writes:
> Well.. the second one will be much slower when the foreign keys verify.
> Primary, unique constraints I'll buy in the create statement. Check
> constraints and defaults are a little fuzzier.
FK, primary, and unique constraints are already split out from the
On Sun, 23 Nov 2003, Tom Lane wrote:
> Actually I'd suggest text[], as there is no good reason to pad the
> array entries to a fixed length.
The only reason against is that all other identifiers have this arbitrary
limit. But sure, text[] would work just as well and without any
restriction.
Is t
On Sun, 23 Nov 2003, Peter Eisentraut wrote:
> How will that work in arbitrary procedural languages?
It is passed along to the handler of the language, and if the language
wants, it can insert these into its environment before execution. I plan
to look at the languages pgsql and sql, but any othe
Here is what I get:
peter ~$ pg-install/bin/initdb pg-install/var/data
...
creating directory pg-install/var/data ... initdb: failed
No points for details in the error message here either.
If I create pg-install/var first, then it work.
--
Peter Eisentraut [EMAIL PROTECTED]
---
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Dennis Bjorklund writes:
>> I'm in the middle of implementing function parameter names.
> So these two reasons make a "namevector" impractical: First, it would
> probably not be in the performance critical path. Second, it would use up
> a fixed leng
Dennis Bjorklund writes:
> I'm in the middle of implementing function parameter names.
How will that work in arbitrary procedural languages?
> Would it be a good idea to create a namevector in the same way as
> oidvector? Would a normal array like name[] be better?
>
> What is the reason for the
I'm in the middle of implementing function parameter names. In pg_proc
the types of the parameters are currently stored as an oidvector, but
how should I store the parameter names?
Would it be a good idea to create a namevector in the same way as
oidvector? Would a normal array like name[] be be
On Sun, 23 Nov 2003, Oleg Bartunov wrote:
> does tsearch2 in 7.4 still has the problem ? I apologies if we miss your
> patches but certainly we're interested in clear explanation of the problem.
The problem was memory allocations made through malloc and family were not
being checked for failure
Rod Taylor wrote:
There might be discussions whether its better to script
CREATE TABLE xxx ..;
ALTER TABLE xxx ADD PRIMARY KEY ;
ALTER TABLE xxx ADD FOREIGN KEY ;
or
CREATE TABLE xxx (, PRIMARY KEY (..), FOREIGN KEY (..));
I'd opt for the second version (a little formatted, maybe :-)
On Sat, Nov 22, 2003 at 11:32:18PM -0400, Marc G. Fournier wrote:
>
> I suspect it might be because I'm running in a jail'd environment, but
> what should I be looking at to confirm?
>
> could not create socket for statistics collector: Protocol not supported
You probably shouldn't worry about i
On Sat, 22 Nov 2003, Joshua D. Drake wrote:
> > Does that mean I have supplied Logictree Systems PostgreSQL? PostgreSQL with
> > Logictree Systems TSearch2?
>
> Actually to some degree, yes. Of course a lot would depend on the type
> of contract you have with them you may be "responsible" for that
44 matches
Mail list logo
