On Sat, Sep 09, 2006 at 01:03:24AM -0400, Jan de Visser wrote:
> On Saturday 09 September 2006 00:42, [EMAIL PROTECTED] wrote:
> > But if the input isn't 32 hexadecimal characters - I don't see how
> > it fits the UUID/GUID type.
> Again, it wasn't about that particular *value* (which, as I
> conc
Jan de Visser wrote:
> On Saturday 09 September 2006 00:42, [EMAIL PROTECTED] wrote:
> > But if the input isn't 32 hexadecimal characters - I don't see how
> > it fits the UUID/GUID type.
>
> Again, it wasn't about that particular *value* (which, as I concurred, is not
> a [GU]UID). It was about
On Saturday 09 September 2006 00:42, [EMAIL PROTECTED] wrote:
> But if the input isn't 32 hexadecimal characters - I don't see how
> it fits the UUID/GUID type.
Again, it wasn't about that particular *value* (which, as I concurred, is not
a [GU]UID). It was about the fact that different tools spi
On Fri, Sep 08, 2006 at 10:49:21PM -0400, Jan de Visser wrote:
> On Friday 08 September 2006 21:34, [EMAIL PROTECTED] wrote:
> > On Fri, Sep 08, 2006 at 09:24:19PM -0400, Jan de Visser wrote:
> > > On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
> > > > 2a) Three input formats are support
"Jeremy Kronuz" <[EMAIL PROTECTED]> writes:
>> I'm reviewing this for addition to contrib/ now. I notice that there is
>> no clear license statement. Is it OK to put the following into the
>> README file?
> Tom, yes. Also, I just put copyright in the files that contain a significant
> amount of
"Jeremy Kronuz" <[EMAIL PROTECTED]> writes:
> Hello again,This is an usable version of my EAN13/UPC/ISBN module.
I'm reviewing this for addition to contrib/ now. I notice that there is
no clear license statement. Is it OK to put the following into the
README file?
EAN13 - UPC - ISBN (books)
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Here is a new patch that replaces the previous one; it adds two
> macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
> respectively.
> I did not only add them to the Makefile for interfaces/libpq,
> but also everywhere something is linked ag
On Friday 08 September 2006 21:34, [EMAIL PROTECTED] wrote:
> On Fri, Sep 08, 2006 at 09:24:19PM -0400, Jan de Visser wrote:
> > On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
> > > 2a) Three input formats are supported.
> > > example:
> > > insert into tbl (fld) values('1dfb39af-b56a-40
On 9/8/06, Xiaofeng Zhao <[EMAIL PROTECTED]> wrote:
I tried to build postgresql from src using vc++ 2005 but was not able to go
far before hitting errors related to inline function in the "wchar.c" file.
The source file I downloaded is "postgresql-8.1.4.tar.gz". I tried to build
it by runing
I tried to build postgresql from src using vc++
2005 but was not able to go far before hitting errors related to inline function
in the "wchar.c" file.
The source file I downloaded is
"postgresql-8.1.4.tar.gz". I tried to build it by runing "nmake -f
win32.mak" in the "src" directory.
On Fri, Sep 08, 2006 at 09:24:19PM -0400, Jan de Visser wrote:
> On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
> > 2a) Three input formats are supported.
> > example:
> > insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
> > insert into tbl (fld) values('{1dfb39af-b5
On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
> 2a) Three input formats are supported.
> example:
> insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
> insert into tbl (fld) values('{1dfb39af-b56a-40b8-a903-b5b31567c3ce}');
> insert into tbl (fld) values('1dfb39afb56
On Fri, Sep 08, 2006 at 05:20:18PM -0400, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > I think what you are saying is that the domain checking (proposed constraint
> > existence checking) would need to be done in more places and I'm not sure I
> > understand this.
>
> What I'm complain
On Fri, Sep 08, 2006 at 04:49:22PM -0400, Andrew Dunstan wrote:
> [EMAIL PROTECTED] wrote:
> >Only ASCII values store more space efficiently in UTF-8. All values
> >over 127 store more space efficiently using UTF-16.
> This second statement is demonstrably not true. Only values above 0x07ff
> req
I have a system by which I store complex data in PostgreSQL as an XML
string. I have a simple function that can return a single value.
I would like to return sets and sets of rows from the data. This is not a
huge problem, as I've written a few of these functions. The question I'd
like to put out
elein <[EMAIL PROTECTED]> writes:
> I think what you are saying is that the domain checking (proposed constraint
> existence checking) would need to be done in more places and I'm not sure I
> understand this.
What I'm complaining about is the need to search the catalogs to see if
a datatype has
On Fri, Sep 08, 2006 at 04:49:49PM -0400, Alvaro Herrera wrote:
> Actually he muttered something about iterators, and not needing to
> convert anything.
Yes, many of the useful functions accept strings in two forms, either
UTF-16 or CharacterIterators. The iterator pretty much only has to know
how
On Fri, Sep 08, 2006 at 03:47:23PM -0400, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > a) if subtypes/domains can have constraints then the model should
> >not be different for domains only but for all types. Constraint
> >checking would only
> >occur at check constraint po
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Do you want me to propose a patch or do you prefer to work on it
> yourself?
It's done already ...
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through U
Tom,
On 9/8/06, Tom Lane <[EMAIL PROTECTED]> wrote:
It seems like we should either remove the separate log_duration boolean
or make it work as he suggests. I'm leaning to the second answer now.
Do you want me to propose a patch or do you prefer to work on it
yourself? If so, do we keep the lo
[EMAIL PROTECTED] wrote:
Only ASCII values store more space efficiently in UTF-8. All values
over 127 store more space efficiently using UTF-16.
This second statement is demonstrably not true. Only values above 0x07ff
require more than 2 bytes in UTF-8. All chars up to that point are
sto
[EMAIL PROTECTED] wrote:
> On Fri, Sep 08, 2006 at 04:42:09PM -0400, Alvaro Herrera wrote:
> > But Martijn already clarified that ICU does not actually force you to
> > switch everything to UTF-16, so this is not an issue anyway.
>
> If my memory is correct, it does this by converting it to UTF-1
On Fri, Sep 08, 2006 at 04:42:09PM -0400, Alvaro Herrera wrote:
> [EMAIL PROTECTED] wrote:
> > The authors of the library in question? Java? Anybody whose primary
> > alphabet isn't LATIN1 based? :-)
> Well, for Latin-9 alphabets, Latin-9 is still more space-efficient than
> UTF-8. That covers a l
On Fri, 2006-09-08 at 16:17 -0400, Tom Lane wrote:
> Gevik Babakhani <[EMAIL PROTECTED]> writes:
> > typreceive = not supported
> > typsend = not supported
>
> Really? Why not?
You are right, typreceive/typsend are also needed.
How would you advice to test this?
> I would suggest that the defau
[EMAIL PROTECTED] wrote:
> On Fri, Sep 08, 2006 at 02:39:03PM -0400, Alvaro Herrera wrote:
> > [EMAIL PROTECTED] wrote:
> > > I think I've been involved in a discussion like this in the past. Was
> > > it mentioned in this list before? Yes the UTF-8 vs UTF-16 encoding
> > > means that UTF-8 applica
On Fri, Sep 08, 2006 at 02:39:03PM -0400, Alvaro Herrera wrote:
> [EMAIL PROTECTED] wrote:
> > I think I've been involved in a discussion like this in the past. Was
> > it mentioned in this list before? Yes the UTF-8 vs UTF-16 encoding
> > means that UTF-8 applications are at a disadvantage when us
Just a few comments,
On Fri, Sep 08, 2006 at 09:18:20PM +0200, Gevik Babakhani wrote:
> 5) support functions:
> because uuid could also be used as PK or unique values, additional
> function(s) will be available to produce a uuid value to be used in
> a field's default value like sequences or PL/p
Gevik Babakhani <[EMAIL PROTECTED]> writes:
> typreceive = not supported
> typsend = not supported
Really? Why not?
I would suggest that the default output format just be 32 hex
characters, since that would render the type useful for purposes
other than one narrow definition of UUID.
Martijn van Oosterhout wrote:
Just a few comments,
On Fri, Sep 08, 2006 at 09:18:20PM +0200, Gevik Babakhani wrote:
5) support functions:
because uuid could also be used as PK or unique values, additional
function(s) will be available to produce a uuid value to be used in
a field's default
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > No one has mentioned that we page value on disk to match the CPU
> > alignment. This is done for efficiency, but is not strictly required.
>
> Well, it is unless you are willing to give up support of non-Intel CPUs;
> most other popu
On Fri, Sep 08, 2006 at 03:20:00PM -0400, Tom Lane wrote:
> "Albe Laurenz" <[EMAIL PROTECTED]> writes:
> > I did not only add them to the Makefile for interfaces/libpq,
> > but also everywhere something is linked against libpq in case
> > somebody links static.
> If we do need to start mentioning
elein <[EMAIL PROTECTED]> writes:
> a) if subtypes/domains can have constraints then the model should
>not be different for domains only but for all types. Constraint
>checking would only
>occur at check constraint points--and there for any type. You
>already check for the exista
On Fri, Sep 08, 2006 at 02:33:13PM -0400, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > Domains and subtypes.
>
> >* Create new child type from values in parent type.
> >* Maintain only checks for constraints
> >* Create implicit casts from child to parent
>
> This seems a b
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Fri, Sep 08, 2006 at 09:28:21AM -0400, [EMAIL PROTECTED] wrote:
> > > But that won't help in the example you posted upthread, because char(N)
> > > is not fixed-length.
> >
> > It can be fixed-length, or at least, have an upper bo
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> I did not only add them to the Makefile for interfaces/libpq,
> but also everywhere something is linked against libpq in case
> somebody links static.
I intensely dislike that part of the patch, but will work on applying
the rest.
If we do need to star
Folks,
I would like to submit the following proposal regarding the
implementation of the GUID datatype. Based on the findings, thoughts and
the discussion we have had in the past, I am going to propose the
following:
1) Datatype name would be "uuid" or "guid".
example: create table tbl (fld uuid,
Bruce Momjian wrote:
No one has mentioned that we page value on disk to match the CPU
alignment. This is done for efficiency, but is not strictly required.
From time to time the idea of a logical vs physical mapping for columns
has been mentioned. Among other benefits, that might allow u
Bruce Momjian <[EMAIL PROTECTED]> writes:
> No one has mentioned that we page value on disk to match the CPU
> alignment. This is done for efficiency, but is not strictly required.
Well, it is unless you are willing to give up support of non-Intel CPUs;
most other popular chips are strict about a
Gregory Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> > > But I think this is a dead-end route. What you're looking at is the
> > > number "1"
> > > repeated for *every* record in the table. And what your proposing amounts
> > > to
> > > noticing that the
Manuel Sugawara writes:
> I don't think so, search_path has its default value and also I'm able
> to reproduce it in a fresh cluster (tried 3 different machines to
> discard hardware problems).
Hm, well I'm willing to take a look if you can provide me access to the
problem database running on a d
[EMAIL PROTECTED] wrote:
> I think I've been involved in a discussion like this in the past. Was
> it mentioned in this list before? Yes the UTF-8 vs UTF-16 encoding
> means that UTF-8 applications are at a disadvantage when using the
> library. UTF-16 is considered more efficient to work with for
On Fri, Sep 08, 2006 at 12:57:29PM -0400, Tom Lane wrote:
> Ah, you're right, I did misunderstand that. However, it's still
> apparently the case that ICU works mostly with UTF16 and handles other
> encodings only via conversion to UTF16. That's a pretty serious
> mismatch with our needs --- we'l
elein <[EMAIL PROTECTED]> writes:
> Domains and subtypes.
>* Create new child type from values in parent type.
>* Maintain only checks for constraints
>* Create implicit casts from child to parent
This seems a bit content-free, because it's not clear how it differs
from what we do now
Tom Lane <[EMAIL PROTECTED]> writes:
> You seem to have worse problems than that, because as given the
> insc_registra_grupo function never returns non-NULL
Actually the function (and the database) is quite complex and was
trimed just to test the problem.
> I suspect pilot error --- perhaps look
On Fri, Sep 08, 2006 at 12:57:29PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> >> AFAICT, most of the useful operations work on UChar, which is uint16:
> >> http://icu.sourceforge.net/apiref/icu4c/umachine_8h.html#6bb9fad572d65b30=
> > 5324ef288165e2ac
> > Oh, you're confusing UCS-2
Manuel Sugawara writes:
> Using the second plan the query is returning tuples where
>a=F1o_semestre <> 20071
You seem to have worse problems than that, because as given the
insc_registra_grupo function never returns non-NULL, and so the
query ought not be returning any tuples at all. I suspe
On Thu, Sep 07, 2006 at 07:12:17PM -0700, Josh Berkus wrote:
> Elein,
>
> > I may have missed some stuff here. Obviously. For example how to divide
> > and conquer the various aspects of the issues raised here. But this is a
> > high, high level proposal at this time.
>
> I'm not quite clear on
Hi all,
I'm running PostgreSQL v 8.1.4 and found a query that returns tuples
that does not satisfy the WHERE clause, the query is:
select * into errores_20071 from (
select r.id, r.trayectoria_id, r.grupo_id,
regacd.insc_registra_grupo(trayectoria_id, grupo_id, true, false, true) as
error
Martijn van Oosterhout writes:
>> AFAICT, most of the useful operations work on UChar, which is uint16:
>> http://icu.sourceforge.net/apiref/icu4c/umachine_8h.html#6bb9fad572d65b30=
> 5324ef288165e2ac
> Oh, you're confusing UCS-2 with UTF-16,
Ah, you're right, I did misunderstand that. However,
Praveen Kumar N wrote:
>
> one more doubt.in the following example we dont need sort right.But in
> this case also relations were scanned sequentially one by one.
In this case it's because the result from one seqscan was materialized.
> So is it the
> case that any relation is accessed only on
one more doubt.in the following example we dont need sort right.But in
this case also relations were scanned sequentially one by one.So is it the
case that any relation is accessed only once from database while executing
a given query?
praveen=# explain select count(*) from a_9000_0,b_9000
On Fri, Sep 08, 2006 at 12:19:19PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Fri, Sep 08, 2006 at 10:35:58AM -0400, Tom Lane wrote:
> >> what's more, the docs suggest that it doesn't support anything wider
> >> than UTF16.
>
> > Well, that's not true, which part of the docs w
Martijn van Oosterhout writes:
> On Fri, Sep 08, 2006 at 10:35:58AM -0400, Tom Lane wrote:
>> what's more, the docs suggest that it doesn't support anything wider
>> than UTF16.
> Well, that's not true, which part of the docs were you looking at?
AFAICT, most of the useful operations work on UCh
On Fri, Sep 08, 2006 at 10:35:58AM -0400, Tom Lane wrote:
> The reason this is a relevant consideration: we are talking about
> changes that would remove existing functionality for people who don't
> have that library.
Huh? If you don't select ICU at compile time you get no difference from
what we
One of the new ecpg tests for comments fails to compile the resulting .c
file, because my vendor C compiler doesn't like '//' style comments,
when running in C mode.
Specifically its line 12 of comment.pgc:
// we also understand this style
It seems like ecpg should translate the comment from '//'
Martijn van Oosterhout writes:
> I'm still missing the argument of why you can't just make a 16-byte
> type. Around half the datatypes in postgresql are fixed-length and have
> no header. I'm completely confused about why people are hung up about
> bytea(16) not being fixed length when it's triv
Martijn van Oosterhout writes:
> On Thu, Sep 07, 2006 at 04:57:04PM -0400, Gregory Stark wrote:
>> Uhm, an ICU source tree is over 40 *megabytes*.
> I don't understand this argument. No-one asked what size the LDAP
> libraries were when we added support for them. No-one cares that
> libssl/libcry
Praveen Kumar N wrote:
On Fri, 8 Sep 2006, Heikki Linnakangas wrote:
Looks like Alvaro guessed right. It reads both relations in sequence,
sorts them in temporary storage, outside bufmgr, and then does a
merge join on the sorted inputs.
could you tell me how can we trace that? I mean which f
On Fri, 8 Sep 2006, Heikki Linnakangas wrote:
Date: Fri, 08 Sep 2006 15:22:19 +0100
From: Heikki Linnakangas <[EMAIL PROTECTED]>
To: Praveen Kumar N <[EMAIL PROTECTED]>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] postgresql shared buffers
Praveen Kumar N wrote:
Following is the ou
Praveen Kumar N wrote:
Following is the output of query i have executed.
Looks like Alvaro guessed right. It reads both relations in sequence,
sorts them in temporary storage, outside bufmgr, and then does a merge
join on the sorted inputs.
If you want to see the behavior you expected, I t
Following is the output of query i have executed.
praveen=# explain select count(*) from a_9000_0,b_9000_0 where a2=b2;
QUERY PLAN
Aggregate (cost=1924635.42..1924635.43 ro
Heikki Linnakangas wrote:
> Praveen Kumar N wrote:
> >Let me explain once more.
> >
> >I have two relations which are 10 times more than bufferpool size.I
> >have observed the following things when joined that two relations(it
> >using merge join to join both relations)
> >
> >1.It first accessed
Praveen Kumar N wrote:
Let me explain once more.
I have two relations which are 10 times more than bufferpool size.I
have observed the following things when joined that two relations(it
using merge join to join both relations)
1.It first accessed system catalog tables
2.Relation 1
3.Relation
On Fri, Sep 08, 2006 at 09:28:21AM -0400, [EMAIL PROTECTED] wrote:
> > But that won't help in the example you posted upthread, because char(N)
> > is not fixed-length.
>
> It can be fixed-length, or at least, have an upper bound. If marked
> up to contain only ascii characters, it doesn't, at lea
Let me explain once more.
I have two relations which are 10 times more than bufferpool
size.I have observed the following things when joined that two
relations(it using merge join to join both relations)
1.It first accessed system catalog tables
2.Relation 1
3.Relation 2
my doubt is one whol
On Fri, Sep 08, 2006 at 08:50:57AM +0200, Peter Eisentraut wrote:
> Gregory Stark wrote:
> > But it's largely true for OLTP applications too. The more compact the
> > data the more tuples fit on a page and the greater the chance you
> > have the page you need in cache.
> But a linear amount of more
Praveen Kumar N <[EMAIL PROTECTED]> writes:
> hai...
>
> I have installed postgresql from sourcecode.I would like to know
> how pages are replaced in the bufferpool when we join two relations.I tried to
> trace it by editing files
> pgsql/src/backend/storage/buffer/(bufmgr.c,freelist.c).Bu
Praveen Kumar N wrote:
I have installed postgresql from sourcecode.I would like to know
how pages are replaced in the bufferpool when we join two relations.I
tried to trace it by editing files
pgsql/src/backend/storage/buffer/(bufmgr.c,freelist.c).But i feel still I
am missing some info
On Fri, Sep 08, 2006 at 08:57:12AM +0200, Peter Eisentraut wrote:
> Gregory Stark wrote:
> > I think we have to find a way to remove the varlena length header
> > entirely for fixed length data types since it's going to be the same
> > for every single record in the table.
> But that won't help in
hai...
I have installed postgresql from sourcecode.I would like to know
how pages are replaced in the bufferpool when we join two relations.I
tried to trace it by editing files
pgsql/src/backend/storage/buffer/(bufmgr.c,freelist.c).But i feel still I
am missing some information after ob
On Fri, Sep 08, 2006 at 02:14:58PM +0200, Peter Eisentraut wrote:
> So "mathematically", you are right, the collation is a property of the
> operation, not of the operands. But semantically, the operands do
> carry the information of what collation order they would like to be
> compared under,
Peter Eisentraut wrote:
The real problem is that the established method dividing up the locale
categories ignores both the technological and the linguistic reality.
In reality, all properties like lc_collate, lc_ctype, and lc_numeric
are dependent on the property "language of the text".
I don'
Heikki Linnakangas wrote:
> have a default set per-database, per-table or per-column, but it's
> not a property of the actual value of a field. I think that the
> phrase "collation of a string" doesn't make sense.
The real problem is that the established method dividing up the locale
categories i
Hi, Jeremy,
Jeremy Drake wrote:
> I am considering, and I think that in order to get a real test of the
> large objects, I would need to load data into a large object which would
> be sufficient to be loaded into more than one block (large object blocks
> were 1 or 2K IIRC) so that the block boun
On Thu, Sep 07, 2006 at 04:57:04PM -0400, Gregory Stark wrote:
> Uhm, an ICU source tree is over 40 *megabytes*. That's almost as much as the
> rest of Postgres itself and that doesn't even include documentation. Even if
> you exclude the data and regression tests you're still talking about dependi
On Fri, Sep 08, 2006 at 11:58:59AM +0100, Heikki Linnakangas wrote:
> Martijn van Oosterhout wrote:
> >I think that if SQL COLLATE gets in we'll get this almost for free.
> >Collation and charset are both properties of strings. Once you've got a
> >mechanism to know the collation of a string, you j
On Fri, Sep 08, 2006 at 05:38:27AM -0400, Andrew Dunstan wrote:
> We can, although I have tried to keep the order fairly logical. Are we
> seeing so many ECPG failures that it's a major blocker? bustard has had
> one ECPG failure in the last 5 days. We are currently only reporting
> failures on
Martijn van Oosterhout wrote:
I think that if SQL COLLATE gets in we'll get this almost for free.
Collation and charset are both properties of strings. Once you've got a
mechanism to know the collation of a string, you just attach the
charset to the same place. The only difference is that changin
On Fri, Sep 08, 2006 at 05:54:01AM -0400, Andrew Dunstan wrote:
> >The encoding is set per-database. Even if you need UTF-8 to encode
> >user-supplied strings, there can still be many small ASCII fields in
> >the database. Country code, currency code etc.
>
> ISTM we should revisit this when we
Heikki Linnakangas wrote:
Gregory Stark wrote:
But why would you use UTF8 to encode fixed length ascii strings?
The encoding is set per-database. Even if you need UTF-8 to encode
user-supplied strings, there can still be many small ASCII fields in
the database. Country code, currency code
Gregory Stark wrote:
But why would you use UTF8 to encode fixed length ascii strings?
The encoding is set per-database. Even if you need UTF-8 to encode
user-supplied strings, there can still be many small ASCII fields in the
database. Country code, currency code etc.
--
Heikki Linnakangas
Tom Lane wrote:
I see that the buildfarm script seems to be running ecpg-check pretty
early in the sequence. Considering that the ecpg tests are still far
from stable, this seems to be taking away the opportunity to learn as
much as we can from a buildfarm run. Could we run the ecpg tests las
Gregory Stark wrote:
> > But that won't help in the example you posted upthread, because
> > char(N) is not fixed-length.
>
> Sure it is because any sane database--certainly any sane database
> using char(N)--is in C locale anyways.
This matter is completely independent of the choice of locale and
Gregory Stark <[EMAIL PROTECTED]> writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> > > > But that won't help in the example you posted upthread, because
> > > > char(N) is not fixed-length.
> > >
> > > Sure it is because any sane database--certainly any sane da
On 2006-09-08, Gregory Stark <[EMAIL PROTECTED]> wrote:
>> But that won't help in the example you posted upthread, because char(N)
>> is not fixed-length.
>
> Sure it is because any sane database--certainly any sane database using
> char(N)--is in C locale anyways.
You're confusing locale and cha
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
> > > But that won't help in the example you posted upthread, because
> > > char(N) is not fixed-length.
> >
> > Sure it is because any sane database--certainly any sane database
> > using char(N)--is in C locale anyways.
>
> Thi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
> > I think we have to find a way to remove the varlena length header
> > entirely for fixed length data types since it's going to be the same
> > for every single record in the table.
>
> But that won't help in the example you p
87 matches
Mail list logo
