2006/9/16, Gregory Stark [EMAIL PROTECTED]:
Alvaro Herrera [EMAIL PROTECTED] writes:
I don't know if this is the same thing you are talking about, but Oleg
talked to me on the conference about partial sort, which AFAICS it's
about the same thing you are talking about. I think Teodor
This patch fixes a couple of cases where we use
strcasecmp() instead
of
pg_strcasecmp() in fe_connect.c, coming from the LDAP client pathc.
Applied. I found another instance in contrib/hstore, too.
Ah. msvc builds don't currently build /contrib, that's why I missed that
one.
Seems __vc_errcode was used during Visual C++ beta at some
point, and
is now declared deprecated in the system headers. This
patch renames
our use of it to __msvc_errcode, so we don't conflict anymore.
If we need this change in plpython, why not also
src/include/port/win32.h?
On 9/16/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
It might make sense to log _what_ is going on, without telling all the
little details, for example
LOG: parse duration: 0.250 ms
LOG: bind duration: 0.057 ms
LOG: execute my_query: SELECT * FROM shop WHERE $1 = $2
DETAIL: parameters: $1 =
This patch adds a required include file to regress.c,
required to get
at InvalidTransactionId.
If that's needed, why isn't everybody else's build falling over too?
Uh, because it's already included 4 lines up?! I must've been tired when
I wrote that patch.
Must've been something wrong
On 9/16/06, Tom Lane [EMAIL PROTECTED] wrote:
The only asymmetry in the thing is that if log_statement fired then
we suppress duplicate printing of the query in the later duration log
message (if any) for that query. But that seems like the right thing
if you're at all concerned about log
Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
Couldn't you just sort by the table names, and ANALYZE the tables in
that order? Would that effectively prevent the deadlocks?
That'd work too, I think (I suggested the variant of ordering by OID,
which is simpler and more reliable). Not
Joshua D. Drake wrote:
O.k. that was negative, sorry. Frankly I think that turning autovacuum
on by default pretty much equates to, I am lazy, and I don't want to
actually evaluate my needs. Lets just go with MS Access
Please ignore my negativity today. I apologize. I do not want autovacuum
First, I asked about this on #postgresql, and I realize that this request
would be a low priority item. Yet, it would be an improvement for security
reasons.
When creating a function using EXTERNAL SECURITY DEFINER, by default PUBLIC
has execute privileges on it. That's unexpected given that
Gregory Stark [EMAIL PROTECTED] writes:
The user would have to decide that he'll never need a value over 127 bytes
long ever in order to get the benefit.
Weren't you the one that's been going on at great length about how
wastefully we store CHAR(1) ? Sure, this has a somewhat restricted
use
Magnus Hagander [EMAIL PROTECTED] writes:
(I seem to have something funky in my cvs repo in general - doing a cvs
diff gives me a *huge* diff for files like gram.c that I thought weren't
supposed to be in cvs at all. Any ideas on why that would be? (I'm
rsync:ing to a local repository and then
Guillaume Smet [EMAIL PROTECTED] writes:
My only concern was that we now have less information with
log_statement='all' than with log_min_duration_statement.
Well, you don't have the durations, but log_statement isn't supposed to
tell you that. So I'm still quite confused about what it is that
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
The user would have to decide that he'll never need a value over 127 bytes
long ever in order to get the benefit.
Weren't you the one that's been going on at great length about how
wastefully we store CHAR(1) ?
Theo Schlossnagle [EMAIL PROTECTED] writes:
The select function is dbi-link's remote_select.
remote_select will perform the query and then for each row
return_next which calls the SPI.xs stuff to do plperl_return_next
which is wrapped in a PG_TRY block. I see the value of the try block
(I seem to have something funky in my cvs repo in general - doing a
cvs diff gives me a *huge* diff for files like gram.c that
I thought
weren't supposed to be in cvs at all. Any ideas on why that
would be?
(I'm rsync:ing to a local repository and then running against that
one))
Magnus Hagander [EMAIL PROTECTED] writes:
There are also some occurrences in pgbench.c, but I'm unsure
that we need be paranoid about changing those.
If we ever want to be able to compile it on a platform that doesn't have
strcasecmp() (such as MSVC++), we would, no?
OK, replaced 'em all.
Magnus Hagander [EMAIL PROTECTED] writes:
If we need this change in plpython, why not also
src/include/port/win32.h?
That's a very good question. It is because something that's pulled in
from the python headers causes the deprecation to show. Whereas when we
compile other things, the
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Weren't you the one that's been going on at great length about how
wastefully we store CHAR(1) ? Sure, this has a somewhat restricted
use case, but it's about as efficient as we could possibly get within
that use
Tom Lane wrote:
To review: Bruce is
proposing a var-length type structure with the properties
first byte 0xxx field length 1 byte, exactly that value
first byte 1xxx xxx data bytes follow
This can support *any* stored value from zero to 127 bytes long.
Andrew Dunstan [EMAIL PROTECTED] writes:
I like this scheme a lot - maximum bang for buck.
Is there any chance we can do it transparently, without exposing new
types? It is in effect an implementation detail ISTM, and ideally the
user would not need to have any knowledge of it.
Well,
I am testing the uuid datatype with unique indexing.
I have the following script to generate a table with uuid types:
create table guid(
pk uuid primary key default new_guid(),
f1 varchar(38)
);
insert into guid(f1) values('bla bla');
insert into guid(f1) values('bla bla');
Gevik Babakhani [EMAIL PROTECTED] writes:
I must be doing something very wrong.
Does anyone ever seen such a thing?
Your comparison functions for uuid are inconsistent.
regards, tom lane
---(end of broadcast)---
TIP
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I like this scheme a lot - maximum bang for buck.
Is there any chance we can do it transparently, without exposing new
types? It is in effect an implementation detail ISTM, and ideally the
user would not need to have any
I wrote:
ISTM the right answer is to add xml_is_well_formed() in this release
and have xml_valid as an alias for it, with documentation explaining
that xml_valid is deprecated and will be removed in the next release.
Not hearing any objection, I've done this.
His patch also adds an
On Sun, Sep 10, 2006 at 09:40:51AM -0700, Joshua D. Drake wrote:
In any case the same logic that leads to it being desirable to report all
the
errors to the user in a UI and not just report them one by one also
applies to
the database. I'm not sure it's the most important issue in the
Back when we converted src/timezone to use int64 for pg_time_t, we
wondered what to do about extending the compiled timezone data file
format for int64, so that it would work for years beyound 2038. We
shelved the problem waiting to see what the upstream zic folks would do.
Well, it looks like
Subject wrap test, please ignore.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 9: In versions below 8.0, the
Thank you Tom :)
I was doing strncmp at some point but it did not work because
of the '\0'. I have created a custom comparison function and it seems to
work. I am now inserting 6 million records to see if it will break again
and start the other tests from scratch.
Thank you for your help.
Gevik Babakhani [EMAIL PROTECTED] writes:
I was doing strncmp at some point but it did not work because
of the '\0'. I have created a custom comparison function and it seems to
work.
Perhaps you just need memcmp instead of strncmp?
regards, tom lane
I have confirmed that my email client, elm-ME+, is wrapping long subject
lines on output, e.g.:
Subject: Re: [COMMITTERS] pgsql: sslinfo contrib module - information
about current SSL
and because majordomo is stripping any secondary lines, the subjects are
getting
Bruce Momjian [EMAIL PROTECTED] writes:
Should I try hacking my mail reader to prevent this? I think I see
where it is happening in the code.
I'd say it'd be better to hack MajorDomo to be RFC-compliant. :)
-Doug
---(end of broadcast)---
TIP
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
Back when we converted src/timezone to use int64 for pg_time_t, we
wondered what to do about
Ühel kenal päeval, R, 2006-09-15 kell 19:18, kirjutas Tom Lane:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, it'll be a 1-byte header with length indicating that no bytes
follow,
Well, in my idea, 1001 would be 0x01. I was going to use the
remaining 7 bits for the
Hannu Krosing wrote:
?hel kenal p?eval, R, 2006-09-15 kell 19:18, kirjutas Tom Lane:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, it'll be a 1-byte header with length indicating that no bytes
follow,
Well, in my idea, 1001 would be 0x01. I was going to use the
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
The user would have to decide that he'll never need a value over 127 bytes
long ever in order to get the benefit.
Weren't you the one that's been going on at great length about how
wastefully we store CHAR(1) ? Sure, this has a
Martjin,
I was actually hoping for more feedback on the content itself. I'm
still not clear if it's supposed to be developers only - to the
exclusion of users or developers only - but accessable to anyone.
It should be readable by everyone, but editable only by authorized users.
--
Josh
Peter,
The short status is that we have quite a bit of code ready and willing
for 8.3. Some factions are working on sneaking some of that into 8.2,
but not me. :)
Is there a reason to have this code on pgFoundry in advance of applying it as
patches against the main code? Nickolay
Josh Berkus josh@agliodbs.com writes:
I was actually hoping for more feedback on the content itself. I'm
still not clear if it's supposed to be developers only - to the
exclusion of users or developers only - but accessable to anyone.
It should be readable by everyone, but editable only by
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
The user would have to decide that he'll never need a value over 127 bytes
long ever in order to get the benefit.
Weren't you the one that's been going on at great length about how
wastefully
Greg,
I think the lessons of wikipedia is precisely that you *don't* want to add
such barriers. You want to let people add stuff pretty much freely. That
encourages people to get involved and put up information.
The other lesson of Wikipedia is that maintaining wiki quality for a generally
Magnus Hagander [EMAIL PROTECTED] writes:
Assuming we can sneak this in even though it's feature-freeze,
want me to look for it?
Yeah, please take a look --- seeing the size of the code will
probably help us decide if it's too late for 8.2 or not.
Here goes. Tested only on win32 so far, but
Gregory Stark wrote:
Josh Berkus josh@agliodbs.com writes:
I was actually hoping for more feedback on the content itself. I'm
still not clear if it's supposed to be developers only - to the
exclusion of users or developers only - but accessable to anyone.
It should be readable by everyone,
On Thu, Sep 14, 2006 at 10:24:43AM -0400, Pascal Meunier wrote:
First, I asked about this on #postgresql, and I realize that this request
would be a low priority item. Yet, it would be an improvement for security
reasons.
When creating a function using EXTERNAL SECURITY DEFINER, by default
Mark Dilger wrote:
Wouldn't a 4-byte numeric be a float4 and an 8-byte numeric be a
float8. I'm not sure I see the difference.
Nevermind. I don't normally think about numeric as anything other than
an arbitrarily large floating point type. But it does differ in that
you can specify the
On Thu, Sep 14, 2006 at 11:12:14AM -0400, D'Arcy J.M. Cain wrote:
The benefit of the money type is speed. Because internal operations
are done on integers they can generally be handled by single CPU ops.
My tests on the 64 bit version show 10% to 25% improvement over numeric
for many
On Sat, Sep 16, 2006 at 02:13:49PM -0700, Mark Dilger wrote:
Mark Dilger wrote:
Wouldn't a 4-byte numeric be a float4 and an 8-byte numeric be a
float8. I'm not sure I see the difference.
Nevermind. I don't normally think about numeric as anything other than
an arbitrarily large floating
On Sep 16, 2006, at 5:27 PM, Jim C. Nasby wrote:
On Thu, Sep 14, 2006 at 11:12:14AM -0400, D'Arcy J.M. Cain wrote:
The benefit of the money type is speed. Because internal operations
are done on integers they can generally be handled by single CPU ops.
My tests on the 64 bit version show 10%
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
The user would have to decide that he'll never need a value over 127
bytes
long ever in order to get the benefit.
Weren't you the one that's been going on at
* Theo Schlossnagle ([EMAIL PROTECTED]) wrote:
Would that pose indexing issues? It would also mean that when
joining two tables you'd have to handle some interesting type
conversion issues (at times). We had someone accidentally create a
largish table with userid as numeric and other
This has been saved for the 8.3 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Pavel Stehule wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
This patch doesn't seem to cope with cases
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
The user would have to decide that he'll never need a value over 127
bytes
long ever in order to get the benefit.
Weren't you the one that's been going on at great length about how
wastefully we store CHAR(1) ? Sure, this has a somewhat
Bruce Momjian [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Sure, this helps with CHAR(1) but there were plen
OK.
Ooops, sorry, I guess I sent that before I was finished editing it. I'm glad
you could divine what I meant because I'm not entirely
Joshua D. Drake wrote:
Gregory Stark wrote:
Josh Berkus josh@agliodbs.com writes:
I was actually hoping for more feedback on the content itself. I'm
still not clear if it's supposed to be developers only - to the
exclusion of users or developers only - but accessable to anyone.
It should be
I followed your advice 6 million records are inserted without any
problems :)
Thank you.
On Sat, 2006-09-16 at 14:03 -0400, Tom Lane wrote:
Gevik Babakhani [EMAIL PROTECTED] writes:
I was doing strncmp at some point but it did not work because
of the '\0'. I have created a custom
Josh Berkus josh@agliodbs.com writes:
The other lesson of Wikipedia is that maintaining wiki quality for a
generally
editable wiki requires a full-time dedicated staff. We don't even have any
volunteers who have 4 hours/week to commit to cleaning up the wiki, unless
you're
Theo Schlossnagle [EMAIL PROTECTED] writes:
Would that pose indexing issues? It would also mean that when joining two
tables you'd have to handle some interesting type conversion issues (at
times). We had someone accidentally create a largish table with userid as
numeric and other tables
On Thu, Sep 14, 2006 at 11:32:09PM +0200, Peter Eisentraut wrote:
Gevik Babakhani wrote:
As suggested in earlier discussion we provide a raw/plain output of
the uuid type:
devdb=# select * from tbluuid;
pk|
--+
The development of the uuid datatype is yet in progress...
I was wondering if I should go ahead and add a macro datatype like the
SERIAL, only this time for the uuid.
something like:
create table tbl
(
mypk SERIALGUID;
)
which creates
create table tbl
(
mypk uuid default
Tom Lane [EMAIL PROTECTED] writes:
The real question is why does the subtransaction actually assign itself
an XID --- a simple RETURN NEXT operation ought not do that, AFAICS.
What is it you're doing in there that changes the database?
I suspect the answer to that is the same as the answer
Gregory Stark wrote:
Josh Berkus josh@agliodbs.com writes:
The other lesson of Wikipedia is that maintaining wiki quality for a generally
editable wiki requires a full-time dedicated staff. We don't even have any
volunteers who have 4 hours/week to commit to cleaning up the wiki, unless
On Thu, Sep 14, 2006 at 02:36:22PM -0700, Joshua D. Drake wrote:
But on a serious note, the problem I run into is exactly the opposite.
Someone will turn on autovacuum because they thought it was a good idea
and for their work load, it isn't. So instead of creating new and
interesting ways
Jim C. Nasby wrote:
On Thu, Sep 14, 2006 at 02:36:22PM -0700, Joshua D. Drake wrote:
But on a serious note, the problem I run into is exactly the opposite.
Someone will turn on autovacuum because they thought it was a good idea
and for their work load, it isn't. So instead of creating new and
* Gregory Stark ([EMAIL PROTECTED]) wrote:
In any case I think Jim was suggesting this be handled internally to the
numeric data type which wouldn't cause this problem. However I'm not sure
anything has to be done. A numeric is an array of 16 bit integers, so anything
under 64k *is* stored
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The real question is why does the subtransaction actually assign itself
an XID --- a simple RETURN NEXT operation ought not do that, AFAICS.
I suspect the answer to that is the same as the answer to what's actually
Hannu Krosing [EMAIL PROTECTED] writes:
why not go all the way, and do utf-7 encoded header if hi bit is set ?
or just always have an utf-8 encoded header.
That definition is (a) very expensive to scan, and (b) useless for
anything except utf-8 encoded text. Whatever mechanism we select should
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Sep 14, 2006 at 10:24:43AM -0400, Pascal Meunier wrote:
My request is to allow changing default permissions for function creation, a
la umask, or at least not give PUBLIC execute permissions by default.
Hrm... do we have any other objects that
Joshua D. Drake [EMAIL PROTECTED] writes:
Gregory Stark wrote:
A TODO list people can freely add stuff to is precisely what would make it
useful. It would have things we don't already know.
I am just going to hope that you are kidding about this one.
Fortunately, none of the real developers
Gevik Babakhani [EMAIL PROTECTED] writes:
I was wondering if I should go ahead and add a macro datatype like the
SERIAL, only this time for the uuid.
This assumes a fact not in evidence, which is that we're going to accept
a uuid-generation function as part of core. AFAIK the only reasonably
Jim C. Nasby [EMAIL PROTECTED] writes:
Then we should change autovacuum so that it stays out of the way when
tables are being vacuumed frequently enough via an external means.
What makes you think it doesn't do that already? Of course, it has its
own ideas about what frequently enough is, but
Magnus Hagander [EMAIL PROTECTED] writes:
Any view over the full timezone names should also include the
corresponding data from zone.tab in the timezone library source.
Just noticed this mail, so that's not included in my patch.
BTW, now that the view is in, I can't help noticing that it
Teodor,
Attached is a diff -c against your original gindocs patch. I did my
best not to change any of the semantics. My changes no doubt overlap
conflict with those Jeff Davis sent you earlier, so consider both of our
diffs.
Thanks,
Dave Fuhry
Teodor Sigaev wrote:
Patch adds GIN
71 matches
Mail list logo
