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 Teodo
> > 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/win
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
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 volu
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 whe
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 a
"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
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
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
> > (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
"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 '
"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,
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
>> t
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');
inser
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)---
TI
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 xpath_
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
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 the
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 planne
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 truncate
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)---
T
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 exte
Ü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
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
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 h
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.
--
Jo
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 submit
Josh Berkus 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 authori
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
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 win
Gregory Stark wrote:
Josh Berkus 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 onl
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 defa
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 th
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 opera
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
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 o
* 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 ot
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
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 somewha
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 n
Joshua D. Drake wrote:
Gregory Stark wrote:
Josh Berkus 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 eve
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 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 volunteering.
Bullshit.
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
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 new_guid
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 answ
Gregory Stark wrote:
Josh Berkus 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 volunteering.
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 wa
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 act
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 sho
"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 obje
"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 de
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 reasonabl
"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" i
"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
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 do
[already sent a variant of that yesterday but it doesn't look like it
made it to the list]
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Apparently we've made the planner a bit too optimistic about the savings
>>> that can be expected from repeated index
72 matches
Mail list logo