Bruce Momjian wrote:
Neil Conway wrote:
On Sat, 2007-05-05 at 20:52 -0400, Bruce Momjian wrote:
What? We don't pass float as a binary to clients.
Sure we do, if the client is sending or receiving data in binary format.
But in those cases, we assume the client and server have the same
On Sun, May 06, 2007 at 08:48:28PM -0400, Tom Lane wrote:
What we've basically got here is a complaint that the default
textual-representation-based method for transmitting PL function
parameters and results is awkward and inefficient for bytea.
So the first question is whether this is really
Martijn van Oosterhout schrieb:
...
I do have one problem though: for bytea/integers/floats Perl has
appropriate internel representations. But what about other user-defined
types? Say the user-defined UUID type, it should probably also passed
by a byte string, yet how could Perl know that.
On May 6, 2007, at 8:18 AM, Andrew Dunstan wrote:
Oh, the answer to Bruce's question about when to create a feature
item? You could well do it at the time when today you create a TODO
item. However, we might even do better. For example, we might well
add feature requests that are denied.
Hi,
As replied to Patch queue triage by Tom, here's simplified patch to
mark WAL record as compressable, with no increase in WAL itself.
Compression/decompression commands will be posted separately to PG
Foundary for further review.
---
As suggested by Tom, I agree
Jim Nasby wrote:
People have suggested different trackers that have varying amounts of
email capability, but I don't think any of them have had the full
capability that we'd need. At best they might accept comments on a
bug/issue via email, but to work for the community they'd need to go
Sorry for late responce due to very long vacation season in Japan.
Tom Lane wrote:
* Re: [PATCHES] [HACKERS] Full page writes improvement, code update
/Koichi Suzuki/
I feel that we have to insist that this be modified to not create
any WAL
bloat in the pre-compression form.
Tom Lane wrote:
My GUC proposal would have made it language+type specific, but Tom
didn't like that approach.
It may indeed need to be language+type specific; what I was objecting to
was the proposal of an ad-hoc plperl-specific solution without any
consideration for other languages
On May 6, 2007, at 8:07 PM, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
Also, what would be the appropriate way to put this into initdb?
You seem to have missed a step here, which is to convince people that
these belong in core at all. So far I've not even seen an argument
that
Tino Wildenhain wrote:
Martijn van Oosterhout schrieb:
...
I do have one problem though: for bytea/integers/floats Perl has
appropriate internel representations. But what about other user-defined
types? Say the user-defined UUID type, it should probably also passed
by a byte string, yet
On May 7, 2007, at 7:47 AM, Zdenek Kotala wrote:
Jim Nasby wrote:
And you describe current processes based on email communication.
But if we setup some tracker some process will be changed. I think
first step is determine what we really want and after we can
discuss how to reach it.
If
On May 6, 2007, at 4:38 PM, Hiroshi Inoue wrote:
Under what license is this file distributed ?
Could you please reply to my question ?
It's from the PostgreSQL source tree, so whatever license that has.
So what's it ?
Could you please take account of developers in the psqlodbc project
a
Andrew Dunstan schrieb:
Tino Wildenhain wrote:
Martijn van Oosterhout schrieb:
...
I do have one problem though: for bytea/integers/floats Perl has
appropriate internel representations. But what about other user-defined
types? Say the user-defined UUID type, it should probably also passed
Alvaro Herrera wrote:
Jim Nasby wrote:
If we really want to make the logfile the approved method for
monitoring performance, then why do we have the stats infrastructure
at all? It could all be replaced with logging output and pgfouine.
First we'd have to fix the usability problem of
Tino Wildenhain wrote:
Andrew Dunstan schrieb:
Tino Wildenhain wrote:
Martijn van Oosterhout schrieb:
...
I do have one problem though: for bytea/integers/floats Perl has
appropriate internel representations. But what about other
user-defined
types? Say the user-defined UUID type, it
Andrew Dunstan [EMAIL PROTECTED] writes:
Tino Wildenhain wrote:
Andrew Dunstan schrieb:
This does not need to be over-engineered, IMNSHO.
Well could you explain where it would appear over-engineered?
Anything that imposes extra requirements on type creators seems undesirable.
I'm not
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tino Wildenhain wrote:
Andrew Dunstan schrieb:
This does not need to be over-engineered, IMNSHO.
Well could you explain where it would appear over-engineered?
Anything that imposes extra
Jim Nasby wrote:
On May 2, 2007, at 5:39 PM, Alvaro Herrera wrote:
The recently discovered autovacuum bug made me notice something
that is
possibly critical. The current autovacuum code makes an effort not to
leave workers in a starting state for too long, lest there be
failure
to
I've not seen your reply yet.
Do you have a mind to cooperate with us ?
I wrote:
Peter Eisentraut wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
User Petere wrote:
Log Message:
---
Put Autotools-generated files into subdirectory config/; add macro
files used from PostgreSQL
ITAGAKI Takahiro wrote:
Alvaro Herrera [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro wrote:
I found that autovacuum launcher does not launch any workers in HEAD.
The attached autovacuum-fix.patch could fix the problem. I changed
to use 'greater or equal' instead of 'greater' at the
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
Thanks a lot.
Hiroshi Inoue
Jim Nasby wrote:
On May 6, 2007, at 4:38 PM, Hiroshi Inoue wrote:
Under what license is this
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
I am having difficulty in understanding what the problem is. My
understanding is that using BSD
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
I am having difficulty in understanding what the problem is. My
Just noticed buffile.c:292 doesn't look quite right where
BufFileDumpBuffer calls FileWrite:
bytestowrite = FileWrite(thisfile, file-buffer, bytestowrite);
It looks as though it would write the same data each time the
loop is iterated. Would this be better?
bytestowrite =
I've been studying the SQL spec in a bit more detail and I'm suddenly
thinking that we've got the behavior all wrong in the current
GENERATED/IDENTITY patch. In particular, it looks to me like we've
been implementing GENERATED ALWAYS AS (expr) according to the rules
that the spec in fact lays
I added a field to pg_type, updated all the bootstrap catalog entries,
changed Natts_pg_type, and (I think) fixed the two places in pg_type.c
that construct pg_type entries. However, initdb fails at the sysviews
creation stage - the core dump shows it failing as shown below. Anyone
have a
Kurt Harriman [EMAIL PROTECTED] writes:
Just noticed buffile.c:292 doesn't look quite right where
BufFileDumpBuffer calls FileWrite:
bytestowrite = FileWrite(thisfile, file-buffer, bytestowrite);
It looks as though it would write the same data each time the
loop is iterated. Would this
Andrew Dunstan [EMAIL PROTECTED] writes:
I added a field to pg_type, updated all the bootstrap catalog entries,
changed Natts_pg_type, and (I think) fixed the two places in pg_type.c
that construct pg_type entries. However, initdb fails at the sysviews
creation stage - the core dump shows
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I added a field to pg_type, updated all the bootstrap catalog entries,
changed Natts_pg_type, and (I think) fixed the two places in pg_type.c
that construct pg_type entries. However, initdb fails at the sysviews
creation stage -
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
One thing I've been burnt by in the past is failing to update the
pg_class.h DATA statement to show the right number of columns. Also,
you fixed both representations of the attribute list in pg_attribute.h,
right?
Thanks. Yes, it was
Peter Eisentraut wrote:
Hiroshi Inoue wrote:
I've not seen your reply yet.
You keep sending your emails to randomly invented addresses, so I don't
get them.
Must I mail them directly to you in the first place ?
I'm sending the emails to pgsql-committes and pgsql-hackers also.
Please note
Tom Lane wrote:
Yeah, adding a column to one of the core bootstrap tables is a real
PITA. But I guess we don't do it often enough to justify having more
infrastructure for that.
Maybe we should beef up the comments in those few stratgegic headers
files a bit though.
Now to use the
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
I am having difficulty in understanding what the problem is. My
Joshua D. Drake wrote:
Hiroshi Inoue wrote:
Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it possible for psqlodbc to be LGPL entirely ?
I am
Hiroshi Inoue [EMAIL PROTECTED] writes:
Could someone confirm the following my recognition ?
The LPGL package could add and release a copy of some Postgres BSD
licensed code as LGPL ones together with the current LGPL code and
then the package is still entirely LGPL.
No, the files you
Oracle 10g, MySQL 5, and SQL Server 2005 don't appear to support the
syntax. The SQL:2003 SIGMOD paper [1] indicates pretty clearly that
their intention is for the values of generated columns to be stored on disk:
... commonly used expressions are evaluated once and their results
stored for
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Could someone confirm the following my recognition ?
The LPGL package could add and release a copy of some Postgres BSD
licensed code as LGPL ones together with the current LGPL code and
then the package is still entirely LGPL.
Alvaro Herrera [EMAIL PROTECTED] writes:
We could have the postmaster signal the launcher, but the signal cannot
contain much useful info because the postmaster does generally not want
to write in shared memory.
The postmaster already touches/writes in shared memory in pmsignal.c.
The trick
38 matches
Mail list logo
