"Matt Miller" <[EMAIL PROTECTED]> writes:
> A few months ago at
> http://archives.postgresql.org/pgsql-general/2006-11/msg01770.php the
> notion of adding an "anyelement2" pseudotype was discussed. The context
> was a compatibility SQL function to support Oracle's DECODE function.
> Assuming this
A few months ago at
http://archives.postgresql.org/pgsql-general/2006-11/msg01770.php the
notion of adding an "anyelement2" pseudotype was discussed. The context
was a compatibility SQL function to support Oracle's DECODE function.
Assuming this new pseudotype has not been added yet, I'm ready to
Just noticed a small cosmetic point in the logs when logging statement
performance data: if a statement accesses 0 blocks, the "hit rate" is
given as 0%.
I can see that that makes sense mathematically--insofar as 0/0 makes
mathematical sense at all--but wouldn't it be more helpful to represent
thi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> ! if (SOCK_ERRNO != ECONNRESET)
> >>> ! SSL_shutdown(conn->ssl);
> >>
> >> Ummm ... what is this supposed to fix exactly, and
Would someone update this patch with the optimization below. The patch
is at?
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > What's conce
Added to TODO:
* Clean up casting in /contrib/isn
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00245.php
---
Tom Lane wrote:
> It occurred to me to run the regression tests type_sanity and opr_sanity
> over t
Added to TODO:
* Improve logging of prepared statements recovered during startup
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php
---
Joachim Wieland wrote:
> There have been se
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are we ready to set 'log_min_error_statement = error' by default for
> > 8.3?
>
> We already did that in 8.2.
Oh, interesting. Oops again.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are we ready to set 'log_min_error_statement = error' by default for
> 8.3?
We already did that in 8.2.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to increase y
Tom Lane wrote:
> "Albe Laurenz" <[EMAIL PROTECTED]> writes:
> >> [ Memo to hackers: why is it that log_min_error_statement = error
> >> isn't the default? ]
>
> > To avoid spamming the logs with every failed SQL statement?
>
> Certainly there are people who will turn it off, but that's why it's
Simon Riggs wrote:
> On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
> > Chris Campbell <[EMAIL PROTECTED]> writes:
> > > Is there additional logging information I can turn on to get more
> > > details? I guess I need to see exactly what locks both processes
> > > hold, and what queries they
Peter Eisentraut wrote:
> Regarding the advisory on possibly insecure security definer functions
> that I just sent out (by overriding the search path you can make the
> function do whatever you want with the privileges of the function
> owner), the favored solution after some initial discussion in
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Mon, 12 Feb 2007, Tom Lane wrote:
>> It turns out this isn't sufficient: ri_Check_Pk_Match() wants to
>> generate PK = PK checks, and the PK = FK operator isn't the right one
>> for that.
> Ugh, right, for modifications of the pk side with no action t
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > It'll break most of the functions that we have in our production
> > systems... They're not security definer functions but it's routine for
> > us to switch between different schemas to run a function on.
>
> >
Stephen Frost <[EMAIL PROTECTED]> writes:
> It'll break most of the functions that we have in our production
> systems... They're not security definer functions but it's routine for
> us to switch between different schemas to run a function on.
> What about pushing all the in-function references
Jacob Rief <[EMAIL PROTECTED]> writes:
> I tried to write a trigger using C++.
That is most likely not going to work anyway, because the backend
operating environment is C not C++. If you dumb it down enough
--- no exceptions, no RTTI, no use of C++ library --- then it might
work, but at that poi
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Peter Eisentraut ([EMAIL PROTECTED]) wrote:
>> Regarding the advisory on possibly insecure security definer functions
>> that I just sent out (by overriding the search path you can make the
>> function do whatever you want with the privileges of the fun
What is the status of this feature addition?
---
Stephen Frost wrote:
-- Start of PGP signed section.
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > (However, now that we support nulls in arrays, meseems a more consistent
> > d
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
> Regarding the advisory on possibly insecure security definer functions
> that I just sent out (by overriding the search path you can make the
> function do whatever you want with the privileges of the function
> owner), the favored solution after s
The Darwin dlopen() patch has already been applied. Where are we on the
Bonjour patch? Do we want code that works on Darwin 10.2 and 10.3?
---
Chris Campbell wrote:
> On Oct 8, 2006, at 14:29, Tom Lane wrote:
>
> > Looks
Jacob Rief wrote:
> Is there any convention how to rename such identifiers? If I would
> rename those identifiers (I simply would add an underscore to each of
> them), would such a patch be accepted and adopted onto one of the
> next releases?
Couldn't you do the required renamings as preprocessor
Regarding the advisory on possibly insecure security definer functions
that I just sent out (by overriding the search path you can make the
function do whatever you want with the privileges of the function
owner), the favored solution after some initial discussion in the core
team was to save t
I tried to write a trigger using C++. This requires to include the
following header-files:
extern "C" {
#include
#include
#include
#include
}
Unfortunately some of the included headers define some structs and
functions where a few identifiers are C++ keywords.
The compiler-directive 'extern "
Is there a TODO here?
---
Jim Nasby wrote:
> On Oct 2, 2006, at 6:28 PM, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >> However, the test right above that means that we'll fail if the user
> >> tries som
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> delay. I just stuck a fixed 100msec delay into the accept-failed code
>>> path.
>>
>> Seems worth mentioning that bgwriter sleeps 1 sec in case of failure.
>> (And so does the autovac code I'm currently look
Alvaro Herrera wrote:
Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
We could possibly sleep() a bit before retrying,
just to not suck 100% CPU, but that doesn't really *fix* anything ...
Well, not only that, but the
Tom Lane wrote:
> Jim Nasby <[EMAIL PROTECTED]> writes:
> > On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
> >> We could possibly sleep() a bit before retrying,
> >> just to not suck 100% CPU, but that doesn't really *fix* anything ...
>
> > Well, not only that, but the machine is currently writing
Added to TODO:
* Improve failure message when DROP DATABASE is used on a database that
has prepared transactions
---
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > I think we should set things up so that prepared
On 2/13/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Andrew Hammond wrote:
> The FreeBSD database/postgres* ports depend on them. Which is
> probably why Marc insists on keeping them.
I hesitate to believe that seeing that they don't actually work, whereas
we have heard no complaints that the
Tom Lane skrev:
Is there any cross-check on the correctness of this list?
As have been said, there is a registration service that makes it harder
to steal nicks.
There is no guarantee that anyone who claim to be this or that really is
who he say he is. On the other hand, a lot of us have b
Peter Eisentraut wrote:
> Andrew Hammond wrote:
> > The FreeBSD database/postgres* ports depend on them. Which is
> > probably why Marc insists on keeping them.
>
> I hesitate to believe that seeing that they don't actually work, whereas
> we have heard no complaints that the FreeBSD ports don't
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Andrew Hammond wrote:
>> The FreeBSD database/postgres* ports depend on them. Which is
>> probably why Marc insists on keeping them.
> I hesitate to believe that seeing that they don't actually work, whereas
> we have heard no complaints that the Fre
Jim Nasby <[EMAIL PROTECTED]> writes:
> On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
>> We could possibly sleep() a bit before retrying,
>> just to not suck 100% CPU, but that doesn't really *fix* anything ...
> Well, not only that, but the machine is currently writing to the
> postmaster log a
On Feb 13, 2007, at 12:15 PM, Tom Lane wrote:
Interesting. So accept() fails because it can't allocate an FD, which
means that the select condition isn't cleared, so we keep retrying
forever. I don't see what else we could do though. Having the
postmaster abort on what might well be a transien
> > The FreeBSD database/postgres* ports depend on them. Which is probably
> > why Marc insists on keeping them.
>
> Well, I think that's a horrid dependency to have. Other packaging
> systems (e.g. the RPM builds) seem quite able to split up a single
> unified build into multiple packages - what c
Hello
please add to ToDo: Holdable cursor support in SPI
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
http://messenger.msn.cz/
---(end of broadcast)---
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Any such site is already broken, because with the proposed design, code
>> is only exposed to short-header datums if it is also exposed to toasted
>> datums.
> Well the toaster doesn't run until we were about t
Andrew Hammond wrote:
> The FreeBSD database/postgres* ports depend on them. Which is
> probably why Marc insists on keeping them.
I hesitate to believe that seeing that they don't actually work, whereas
we have heard no complaints that the FreeBSD ports don't work.
--
Peter Eisentraut
http://d
Gregory Stark wrote:
> Alternatively, what does the trailing "a" in varlena signify? Would this be
> varlenb?
"attribute"
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive,
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> You keep suggesting things that I've previously considered and rejected --
>> perhaps prematurely. Off the top of my head I recall the following four
>> options from our discussions. It looks like we're circling
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This is from October 2006. Is there a TODO here?
I think we had decided that the code that's in there is fine.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to in
Andrew Hammond wrote:
On Feb 12, 5:16 pm, [EMAIL PROTECTED] ("Joshua D. Drake") wrote:
Peter Eisentraut wrote:
Jeroen T. Vermeulen wrote:
Is this a known problem? Is there any test procedure that builds the
"base" distribution before release?
Most of the core team is
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> The postmaster is stuck in the following loop, according to
> ktrace/kdump:
> 2023 postgres CALL select(0x8,0xbfffe194,0,0,0xbfffe16c)
> 2023 postgres RET select 1
> 2023 postgres CALL sigprocmask(0x3,0x2f0d38,0)
> 2023 postgres RET sigpro
This is from October 2006. Is there a TODO here?
---
Tom Lane wrote:
> I did a couple more tests using x86 architectures. On a rather old
> Pentium-4 machine running Fedora 5 (gcc 4.1.1, glibc-2.4-11):
>
> $ gcc -O3 -std=
On Feb 12, 5:16 pm, [EMAIL PROTECTED] ("Joshua D. Drake") wrote:
> Peter Eisentraut wrote:
> > Jeroen T. Vermeulen wrote:
> >> Is this a known problem? Is there any test procedure that builds the
> >> "base" distribution before release?
>
> > Most of the core team is convinced that the postgresql-
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Log Message:
> > ---
> > Add ORDER BY to vacummdb so databases are scaned in the same order as
> > pg_dumpall.
>
> If we're gonna do that (which I have no objection to), shouldn't
> clusterdb and reindexdb do the same?
Done,
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Log Message:
> ---
> Add ORDER BY to vacummdb so databases are scaned in the same order as
> pg_dumpall.
If we're gonna do that (which I have no objection to), shouldn't
clusterdb and reindexdb do the same?
regards, tom l
Tom Lane wrote:
> > We detect cases where the typmod guarantees either a fixed size or a maximum
> > size < 256 bytes.
>
> After last week I would veto this option anyway: it fails unless we
> always know typmod exactly, and I'm here to tell you we don't.
If we can pull this off, it handles short
Gregory Stark <[EMAIL PROTECTED]> writes:
> You keep suggesting things that I've previously considered and rejected --
> perhaps prematurely. Off the top of my head I recall the following four
> options from our discussions. It looks like we're circling around option 4.
No, I think I'm arguing for
The 8.1 build for cuckoo is currently hung, with the *postmaster* taking
all the CPU it can get. The build started almost 5 hours ago.
The postmaster is stuck in the following loop, according to
ktrace/kdump:
2023 postgres RET write 59/0x3b
2023 postgres CALL close(0x)
2023 postg
Hey all:
This is a randomly inserted distraction to tell you that I really like to
read about these ideas. No input from myself at this point. I'm happy with
the direction you are taking.
Thanks,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
.
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> Uh, if the macros can read 1 and 4-byte headers, why do we need to
>> allocate memory for them?
> Because the macros can't read 1 and 4-byte headers. If they could we would
> have the problem with VARDATA fo
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The point I'm trying to get across here is to do things one small step
> at a time; if you insist on a "big bang" patch then it'll never get
> done. You might want to go back and review the CVS history for some
> other big changes like TOAST and the versi
Gregory Stark wrote:
>
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> >> But I'm surprised, I had the impression that you were reluctant to consider
> >> memcpying all the data all the time.
> >
> > Uh, if the macros can read 1 and 4-byte headers, why do we need to
> > allocate memory for them
Added to TODO:
* Update our code to handle 64-bit timezone files to match the zic
source code, which now uses them
---
Tom Lane wrote:
> Back when we converted src/timezone to use int64 for pg_time_t, we
> wondered what
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> But I'm surprised, I had the impression that you were reluctant to consider
>> memcpying all the data all the time.
>
> Uh, if the macros can read 1 and 4-byte headers, why do we need to
> allocate memory for them?
Because the macros can't read 1 an
On Tue, 2007-13-02 at 11:38 -0500, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > From an application developer's standpoint there are few options, none
> > of them ideal:
>
> How about
>
> 4) Make all the FK constraints deferred, so that they are only checked
> at end of transactio
Marc Munro <[EMAIL PROTECTED]> writes:
> From an application developer's standpoint there are few options, none
> of them ideal:
How about
4) Make all the FK constraints deferred, so that they are only checked
at end of transaction. Then the locking order of transactions that only
modify C is al
Magnus Hagander <[EMAIL PROTECTED]> writes:
> On Tue, Feb 13, 2007 at 05:23:56PM +0100, Peter Eisentraut wrote:
>> It turns out that gcc warns about it anyway. Does anyone have some sort
>> of clever recipe to catch warnings more easily than by carefully
>> reading the make output or manually gr
Peter Eisentraut wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> > > From what I can tell, this is because the Assert() puts code (the
> > > do {} loop) *before* the declaration of StringInfoData buf, which
> > > is not permitted.
> >
> > This will fail on every ANSI-C co
Based on this patch review, I am removing the patch from the patch
queue and requiring a resubmission.
---
Tom Lane wrote:
> Dhanaraj M <[EMAIL PROTECTED]> writes:
> > Sorry for resubmitting this patch.
> > Just now I found
On Tue, Feb 13, 2007 at 05:23:56PM +0100, Peter Eisentraut wrote:
> Tom Lane wrote:
> > Magnus Hagander <[EMAIL PROTECTED]> writes:
> > > From what I can tell, this is because the Assert() puts code (the
> > > do {} loop) *before* the declaration of StringInfoData buf, which
> > > is not permitted.
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I'd be inclined to put the intelligence into heap_form_tuple and thereby
>> avoid getting the TOAST code involved unless there are wide fields to
>> deal with.
> And have heap_deform_tuple / heap_getattr palloc and me
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > From what I can tell, this is because the Assert() puts code (the
> > do {} loop) *before* the declaration of StringInfoData buf, which
> > is not permitted.
>
> This will fail on every ANSI-C compiler, not just vc. Please fix.
We
On Mon, 2007-12-02 at 00:10 -0500, Tom Lane wrote:
> Marc Munro <[EMAIL PROTECTED]> writes:
> > Consider a table C containing 2 child records C1 and C2, of parent P.
> > If transaction T1 updates C1 and C2, the locking order of the the
> > records will be C1, P, C2. Another transaction, T2, that a
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > > So (nigh) every tuple will get deformed and reformed once before it goes
> > > to
> > > disk? Currently the toast code doesn't even look at a tuple if it's small
> > > enough, but in this case we would want it to fire even on very n
Tom Lane <[EMAIL PROTECTED]> writes:
> > So (nigh) every tuple will get deformed and reformed once before it goes to
> > disk? Currently the toast code doesn't even look at a tuple if it's small
> > enough, but in this case we would want it to fire even on very narrow rows.
>
> I'd be inclined to
Gregory Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > I don't really see a way around it though. Places that fill in VARDATA
> > > before
> > > the size (formatting.c seems to be the worst case) will just have to be
> > > changed and
Magnus Hagander wrote:
> The latest set of XML changes (I think latest, at least fairly recent)
> broke the win32vc build with asserts enabled. The line:
> Assert(fully_escaped || !escape_period);
>
> From what I can tell, this is because the Assert() puts code (the do {}
> loop) *before* th
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> (1) code written to existing practice will always generate 4-byte
>> headers. (Hence, VARDATA() acts the same as now.) That's the format
>> that generally gets passed around in memory.
> So then we don't need to
On Tue, Feb 13, 2007 at 10:50:30AM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > From what I can tell, this is because the Assert() puts code (the do {}
> > loop) *before* the declaration of StringInfoData buf, which is not
> > permitted.
>
> This will fail on every ANSI
Magnus Hagander <[EMAIL PROTECTED]> writes:
> From what I can tell, this is because the Assert() puts code (the do {}
> loop) *before* the declaration of StringInfoData buf, which is not
> permitted.
This will fail on every ANSI-C compiler, not just vc. Please fix.
regard
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > I don't really see a way around it though. Places that fill in VARDATA
> > before
> > the size (formatting.c seems to be the worst case) will just have to be
> > changed and it'll be a fairly fragile point.
>
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> But if you are walking through attributes, how do you know to look at
> the next byte or the next aligned byte? We have to force zeros in
> there?
Yup: pad bytes must be zeroes (they are already) and a 1-byte-header
can't be a zero (easily done if its l
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Heikki Linnakangas wrote:
> >> We would still require all datums with a 4-byte header to be 4-byte
> >> aligned, right? When reading, you would first check if it's a compressed
> >> or uncompressed header. If compressed, read the 1 byte header,
On Tue, Feb 13, 2007 at 04:29:16PM +0100, Magnus Hagander wrote:
> The latest set of XML changes (I think latest, at least fairly recent)
> broke the win32vc build with asserts enabled. The line:
> Assert(fully_escaped || !escape_period);
>
> From what I can tell, this is because the Assert(
On 2/13/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hannu Krosing wrote:
>> Are we actually doing that ? I.E are null bitmaps really allocated in 1
>> byte steps nowadays ?
> Yes.
Not really; we still have to MAXALIGN at the end of the bitmap. The
Bruce Momjian wrote:
Heikki Linnakangas wrote:
We would still require all datums with a 4-byte header to be 4-byte
aligned, right? When reading, you would first check if it's a compressed
or uncompressed header. If compressed, read the 1 byte header, if
uncompressed, read the 4-byte header and
The latest set of XML changes (I think latest, at least fairly recent)
broke the win32vc build with asserts enabled. The line:
Assert(fully_escaped || !escape_period);
>From what I can tell, this is because the Assert() puts code (the do {}
loop) *before* the declaration of StringInfoData
Heikki Linnakangas wrote:
> Gregory Stark wrote:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> For example it'd be easy to implement the previously-discussed design
> >> involving storing uncompressed length words in network byte order:
> >> SET_VARLENA_LEN does htonl() and VARSIZE does ntohl() a
Gregory Stark <[EMAIL PROTECTED]> writes:
> I don't really see a way around it though. Places that fill in VARDATA before
> the size (formatting.c seems to be the worst case) will just have to be
> changed and it'll be a fairly fragile point.
No, we're not going there: it'd break too much code now
On Tue, Feb 13, 2007 at 09:44:03AM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> Could the "new style" macros be back-ported to previous releases in case
> >> we do this?
>
> > Yes, Tom and I talked about this. It could appear in the next minor
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> As far as I understood the proposal, tgargs wouldn't go away, it would
> just not be populated for RI triggers.
Yes, of course. I wasn't suggesting that we take away the ability to
pass arguments to triggers in general.
reg
Gregory Stark wrote:
> a) To have two sets of macros, one of which, VARATT_DATA and
> VARATT_SIZEP are for constructing new tuples and behaves exactly as
> it does now. So you always construct a four-byte header datum. Then
> in heap_form*tuple we check if you can use a shorter header and
> convert
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Could the "new style" macros be back-ported to previous releases in case
>> we do this?
> Yes, Tom and I talked about this. It could appear in the next minor
> release of all branches.
I don't really see the point of that. Th
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> Actually I think neither htonl nor bitshifting the entire 4-byte word is
>> going
>> to really work here. Both will require 4-byte alignment. Instead I think we
>> have to access the length byte by byte as a (char*) and do arithmetic. Since
>> i
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hannu Krosing wrote:
>> Are we actually doing that ? I.E are null bitmaps really allocated in 1
>> byte steps nowadays ?
> Yes.
Not really; we still have to MAXALIGN at the end of the bitmap. The
point is that you can get 8 bits in there before pa
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
For example it'd be easy to implement the previously-discussed design
involving storing uncompressed length words in network byte order:
SET_VARLENA_LEN does htonl() and VARSIZE does ntohl() and nothing else in
the per-datatype function
Magnus Hagander wrote:
> On Mon, Feb 12, 2007 at 11:19:14PM -0500, Tom Lane wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
>
> > By my count there are only 170 uses of VARATT_SIZEP in the entire
> > backend (including contrib) so this is not an especially daunting
> > change. It would break
"Tom Lane" <[EMAIL PROTECTED]> writes:
> If we replaced that line with something like
>
> SET_VARLENA_LEN(result, len + VARHDRSZ);
>
> then we'd have a *whole* lot more control.
I think that part was already clear. The problem was in VARDATA.
I don't really see a way around it though. P
On Mon, Feb 12, 2007 at 08:08:31PM -0500, Robert Treat wrote:
> > In my memory I remember a site that displayed the code coverage of the
> > regression tests, but I can't find it now. Does anybody know?
> >
>
> Are you thinking of spikesource? According to thier numbers, we currently
> cover abou
Robert Treat wrote:
On Saturday 10 February 2007 13:59, Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
I'd say we probably want to keep the tgargs info for at least a version
or two after changing the implementation. Getting rid of using the args
info sounds like a good idea.
We wh
Hannu Krosing wrote:
But actually that 1 free byte in the header is not currently just waste
of space. If you have any nulls in your tuple, there's going to be a
null bitmap in addition to the header. 1 byte is conveniently enough to
store the null bitmap for a table with max 8 columns,
Are w
I've been looking at backporting the stats fix committed to head and 8.2
into 8.1, but realised that it's just not going to work. 8.1 still uses
the dual stats processor stuff, which means that the simplification just
is not possible.
The most obvious result is that autovacuum is very likely to fa
Precise definition for "latin" in C locale please. Are you saying that
single byte encoding with range 0-7f? is "latin"? If so, it seems they
are exacty same as ASCII.
p_islatin returns true for ASCII alpha characters.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED
> > I know. My guess is the parser does not read the stop word file at
> > least with default configuration.
>
> Parser should not read stopword file: its deal for dictionaries.
I'll come up with more detailed info, explaining why stopword file is
not read.
> > So if a character is not ASCII, it
On Mon, Feb 12, 2007 at 11:19:14PM -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> By my count there are only 170 uses of VARATT_SIZEP in the entire
> backend (including contrib) so this is not an especially daunting
> change. It would break existing user-written functions th
I know. My guess is the parser does not read the stop word file at
least with default configuration.
Parser should not read stopword file: its deal for dictionaries.
So if a character is not ASCII, it returns 0 even if p_isalpha returns
1. Is this what you expect?
No, p_islatin should return
On Tue, February 13, 2007 07:39, Tom Lane wrote:
> Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
>
>> Bruce Momjian wrote:
>>
>>> Lukas Kahwe Smith wrote:
>>>
http://developer.postgresql.org/index.php/IRC2RWNames
>>>
>>> Ah, excellent. Should we put this in the IRC topic line?
>>>
>
>> i
99 matches
Mail list logo