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 real
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. Tha
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
bey
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
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 (o
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
wo
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 we
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> 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 fo
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 litt
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 passe
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 pr
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, i
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.
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 requirem
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
> >fail
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
> fi
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
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 file
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 lice
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
understanding
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 = FileWrite(thisf
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 down
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 qui
"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. Wo
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 sh
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 - t
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.
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 n
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 f
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
understanding
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 having
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
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 entir
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 tric
38 matches
Mail list logo
