> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Ok, here is the revised patch.
>
> This looks sane to me, but I'd suggest leaving out the mention of 8.4
> in the docs. Actually, I'm not sure you need a paragraph at all ---
> just adding an example would be enough, I think.
>
> SELECT lo_unlink(
Hi,
We have something that seems to work and may be used as a start point.
Please, take a look at http://gorda.di.uminho.pt/community/pgsqlg/
In particular, take a look at the file src/backend/commands/triggerspecial.
Cheers,
Alfranio.
>
> On Mar 13, 2008, at 5:14 PM, James Mansion wrote:
>
>
Added to TODO:
o Prevent SSL from sending network packets to avoid interference
with Win32 signal emulation
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00455.php
---
Magnus Hagander
Heikki Linnakangas wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
There is your CopyReadLineText speedup, but I think there are too
many open questions on it, e.g.:
...
So I suggest we take it out of the queue for now and kick it back to
you.
Per my comments just now, t
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
There is your CopyReadLineText speedup, but I think there are too many
open questions on it, e.g.:
...
So I suggest we take it out of the queue for now and kick it back to you.
Per my comments just now, the question is whether it's be
I would work on this and try to present the performance test results.
I would also go ahead and examine, whether the logic can be added into
heap_form_tuple by any means.
Thanks,
Gokul.
On Wed, Mar 19, 2008 at 12:11 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> Added to TODO:
>
>* Con
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
There is your CopyReadLineText speedup, but I think there are too many
open questions on it, e.g.:
...
So I suggest we take it out of the queue for now and kick it back to you.
Per my comments just now, the question is wheth
On Fri, Mar 21, 2008 at 10:25 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> A recent message from a would-be mysql converter led me to realize
> that we don't check for array decoration when we expand "serial".
> So this is accepted but doesn't do what one might expect:
>
> regression=# create table f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 21 Mar 2008 12:55:26 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> regression=# create table foo (f1 serial[11]);
> NOTICE: CREATE TABLE will create implicit sequence "foo_f1_seq" for
> serial column "foo.f1" CREATE TABLE
> regression=# \d foo
On Thu, Mar 20, 2008 at 6:41 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Warren Turkal <[EMAIL PROTECTED]> writes:
> > I added TimeOffset and DateOffset typedefs to get rid of the instances
> > using the HAVE_INT64_TIMESTAMP define being used to determine the
> > types of variables or functions in
A recent message from a would-be mysql converter led me to realize
that we don't check for array decoration when we expand "serial".
So this is accepted but doesn't do what one might expect:
regression=# create table foo (f1 serial[11]);
NOTICE: CREATE TABLE will create implicit sequence "foo_f1_
On Thu, Mar 20, 2008 at 6:48 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Warren Turkal" <[EMAIL PROTECTED]> writes:
>
> > I have to say, I am wondering more and more how real the need is for
> > the two representations of timestamps. Would it be better to deprecate
> > the float format or at least
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> There is your CopyReadLineText speedup, but I think there are too many
> open questions on it, e.g.:
> ...
> So I suggest we take it out of the queue for now and kick it back to you.
Per my comments just now, the question is whether it's been adequatel
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Ok, here is the revised patch.
This looks sane to me, but I'd suggest leaving out the mention of 8.4
in the docs. Actually, I'm not sure you need a paragraph at all ---
just adding an example would be enough, I think.
SELECT lo_unlink(173454); -- del
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Umm, I don't think there's any patches from me in the queue that need
> review. There's some discussion threads related to bitmap indexes, but
> that's all. We're definitely not going to get bitmap indexes in this
> commit fest.
I think there a
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> The result will be two datatypes datetime and timestamp_int or
> timestamp_float.
This is not happening, at least not without 100 times more work than
anyone has shown willingness to put into the issue. It seems fairly
clear that everyone thinks the in
Heikki Linnakangas wrote:
Simon Riggs wrote:
Incidentally, I'm in favour of letting Heikki review his own work
because there's a backlog on index changes that appears to be months
long and he has a good chance of tackling that.
Umm, I don't think there's any patches from me in the queue tha
Hans-Juergen Schoenig <[EMAIL PROTECTED]> writes:
> Doing this for XIDs is pretty useless this days.
> It is only targeted for command ids which are consumed heavily by
> stored procedure languages.
> It happens once on a while that a complex business logic procedure
> runs out of command ids i
> > What is evil with a polymorphic function?
>
> (1) It's creating a false match --- your proposed entry in the opr_sanity
> results has nothing at all to do with what the test is looking for.
>
> (2) Refactoring to have two separate C functions will make the code
> clearer, and not noticeably l
On Fri, 2008-03-21 at 08:48 -0400, Bruce Momjian wrote:
> I don't think that list is complete. The full archive is:
>
> http://momjian.us/cgi-bin/pgpatches
>
> Sorry, there is no summary.
I've reviewed Nikhil's partitioning patch for now.
I have some time to contribute, but not much. I
Simon Riggs wrote:
> On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote:
>
> > > Simon, would it be too much to ask that you concentrate on reviewing
> > > existing patches during commit fest? Trying to get people to think
> > > about random new ideas is about the most direct undermining of the
Simon Riggs wrote:
On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote:
Simon, would it be too much to ask that you concentrate on reviewing
existing patches during commit fest? Trying to get people to think
about random new ideas is about the most direct undermining of the
commit-fest concep
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote:
>
>> > Simon, would it be too much to ask that you concentrate on reviewing
>> > existing patches during commit fest? Trying to get people to think
>> > about random new ideas is about the most dir
Tom Lane napsal(a):
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Neil Conway wrote:
Sure -- I sent in a patch earlier, but I'll post an updated version
shortly.
Hmm, I mean just switching the default value in configure.in ... is
there anything else that needs doing at this point?
Well, that'
On Thu, 2008-03-20 at 23:07 +, Simon Riggs wrote:
> > Simon, would it be too much to ask that you concentrate on reviewing
> > existing patches during commit fest? Trying to get people to think
> > about random new ideas is about the most direct undermining of the
> > commit-fest concept that
Reini Urban napsal(a):
cygwin 1.5 on NTFS. But 1.7 will a have much larger _PC_PATH_MAX.
_PC_FILESIZEBITS undefined _PC_LINK_MAX = 8 _PC_NAME_MAX = 260 _PC_PATH_MAX =
257
So this is really bad.
Thanks for reporting. It seems not good because postgreSQL assumes that
_PC_PATH_MAX
is minimal
26 matches
Mail list logo
