Re: [HACKERS] Proposal: new large object API

[Tatsuo Ishii]

> 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);  -- deletes large object with OID 173454
>   
>   INSERT INTO image (name, raster)
>   VALUES ('beautiful image', lo_import('/etc/motd'));
> + 
> + INSERT INTO image (name, raster)  -- same as above, but specify OID to use
> + VALUES ('beautiful image', lo_import('/etc/motd', 68583));
>   
>   SELECT lo_export(image.raster, '/tmp/motd') FROM image
>   WHERE name = 'beautiful image';
>   

Thanks for the comment. I have committed with your suggested doc
changing.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal for db level triggers

[alfranio]

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:
>
>> James Mansion wrote:
>>> In usage:
>>>
>>> AFTER START clears counters and flags.
>>> UPDATE triggers on data set counters and flags.
>>> BEFORE COMMIT examines the counters and flags and performs any
>>> final validation or
>>> adjustments (or external events such as sending a MoM message)
>>>
>> I'd like to point out also that AFTER CONNECT is a good opportunity
>> to CREATE TEMP TABLE (be
>> nice if a global temp table definition could be persisted and
>> automatically duplicated into each session, but
>> never mind).
>
> +1 on both counts. Can we get a TODO?
> --
> Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
> Give your computer some brain candy! www.distributed.net Team #1828
>
>
>



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [EMAIL PROTECTED]: Re: [pgsql-es-ayuda] SLL error 100% cpu]

[Bruce Momjian]

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 wrote:
> On Wed, Dec 12, 2007 at 12:30:50AM -0500, Tom Lane wrote:
> > "Trevor Talbot" <[EMAIL PROTECTED]> writes:
> > > On 12/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > >> I dunno anything about how to fix the real problem (what's winsock error
> > >> 10004?),
> > 
> > > WSAEINTR, "A blocking operation was interrupted by a call to
> > > WSACancelBlockingCall."
> > 
> > Oh, then it's exactly the same thing as our bug #2829.
> > 
> > I opined in that thread that OpenSSL was broken because it failed to
> > treat this as a retryable case like EINTR.  But not being much of a
> > Windows person, that might be mere hot air.  Someone with a Windows
> > build environment should try patching OpenSSL to treat WSAEINTR
> > the same as Unix EINTR and see what happens ...
> 
> When I last looked at this (and this was some time ago), I suspected (and
> still do) that the problem is in the interaction between our
> socket-emulation-stuff (for signals) and openssl. I'm not entirely sure,
> but I wanted to rewrite the SSL code so that *our* code is responsible for
> aclling the actuall send()/recv(), and not OpenSSL. This would also fix the
> fact that if an OpenSSL network operation ends up blocking, that process
> can't receive any signals...
> 
> I didn't have time to get this done before feature-freeze though, and I
> beleive the changes are large enough to qualify as such..
> 
> //Magnus
> 
> ---(end of broadcast)---
> TIP 2: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Commit Fest (was Re: [HACKERS] Sort Refinement)

[Andrew Dunstan]

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, the question is whether it's been adequately
reviewed or still needs some attention from the community.  If we think
the ball's entirely in Heikki's court on it, then we're done with it
until he comes back with a new version (or evidence showing it's good
as-is).


I'm not expecting any more review in this commit fest.

My plan is to try special-casing the usual case of text-mode in a non 
ASCII-embedding encoding (one that can be used as server encoding), by 
using memchr() to find end of line first, and then scanning back from 
there to count preceding backslashes. That requires some refactoring, 
but should avoid the performance penalty when there's plenty of 
backslashes.


Of course, if anyeone has better ideas, please speak up!



That won't work for CSV mode, of course, which leaves us with trying to 
refine your previous solution in that case.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Commit Fest (was Re: [HACKERS] Sort Refinement)

[Heikki Linnakangas]

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 been adequately
reviewed or still needs some attention from the community.  If we think
the ball's entirely in Heikki's court on it, then we're done with it
until he comes back with a new version (or evidence showing it's good
as-is).


I'm not expecting any more review in this commit fest.

My plan is to try special-casing the usual case of text-mode in a non 
ASCII-embedding encoding (one that can be used as server encoding), by 
using memchr() to find end of line first, and then scanning back from 
there to count preceding backslashes. That requires some refactoring, 
but should avoid the performance penalty when there's plenty of backslashes.


Of course, if anyeone has better ideas, please speak up!

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal for Null Bitmap Optimization(for Trailing NULLs)

[Gokulakannan Somasundaram]

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:
>
>* Consider not storing a NULL bitmap on disk if all the NULLs are
>  trailing
>
>  http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php
>  http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php
>
> Tom's comments are:
>
>What this lacks is some performance testing to measure the cost of
> the
>extra tests in heap_form_tuple. If that can be shown to be
> negligible
>then it's probably worth doing  though I don't like any part of
> the
>actually submitted patch ;-). All this should need is a bit more
> logic
>in heap_form_tuple and heap_formtuple.
>
>
> ---
>
> Gokulakannan Somasundaram wrote:
> > Hi,
> > Currently we check for the existence of NULL values in the tuple and
> we
> > set the has_null flag. If the has_null flag is present, the tuple will
> be
> > storing a null bitmap. What i propose is
> >
> > a) By modifying the functions, heap_form_tuple and heap_fill_tuple, we
> can
> > check whether all the nulls are trailing nulls. If all the nulls are
> > trailing nulls, then we will not set the has_null flag and we will not
> have
> > the null bitmap with the tuple.
> >
> > b) While selecting the tuple, we will check whether the tuple offset
> equals
> > / exceeds the length of the tuple and then mark the remaining attributes
> of
> > the tuple as null. To be exact, we need to modify the slot_deform_tuple
> in
> > order to achieve the same.
> >
> > This may not give huge performance benefits, but as you may know, it
> will
> > help is reducing the disk footprint.
> >
> >
> > Expecting your comments..
> >
> > --
> > Thanks,
> > Gokul.
> > CertoSQL Project,
> > Allied Solution Group.
> > (www.alliedgroups.com)
>
> --
>  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
>  EnterpriseDB http://postgres.enterprisedb.com
>
>  + If your life is a hard drive, Christ can be your backup. +
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Re: Commit Fest (was Re: [HACKERS] Sort Refinement)

[Andrew Dunstan]

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 been adequately
reviewed or still needs some attention from the community.  If we think
the ball's entirely in Heikki's court on it, then we're done with it
until he comes back with a new version (or evidence showing it's good
as-is).


  


My comments were intended to say I think the latter is the case (since I 
had previously undertaken to review this patch).


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] serial arrays?

[Gurjeet Singh]

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 foo (f1 serial[11]);
> NOTICE:  CREATE TABLE will create implicit sequence "foo_f1_seq" for
> serial column "foo.f1"
> CREATE TABLE
> regression=# \d foo
> Table "public.foo"
>  Column |  Type   |Modifiers
> +-+--
>  f1 | integer | not null default nextval('foo_f1_seq'::regclass)
>
>
> Should we throw an error for this?


+1


> If not, what behavior would be
> sane?
>
>
I don't see any sane explanation if we do provide that syntax!!!

Best regards,
-- 
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB http://www.enterprisedb.com

17° 29' 34.37"N, 78° 30' 59.76"E - Hyderabad *
18° 32' 57.25"N, 73° 56' 25.42"E - Pune
37° 47' 19.72"N, 122° 24' 1.69" W - San Francisco

http://gurjeet.frihost.net

Mail sent from my BlackLaptop device

Re: [HACKERS] serial arrays?

[Joshua D. Drake]

-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
>  Table "public.foo"
>  Column |  Type   |Modifiers 
> +-+--
>  f1 | integer | not null default nextval('foo_f1_seq'::regclass)
> 
> 
> Should we throw an error for this?  If not, what behavior would be
> sane?

Interesting? Would be to create 11 sequences that can update each
element of the array. Sane? None. We should throw an error. 

Sincerely,

Joshua D. Drake


- -- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH4+m0ATb/zqfZUUQRAhNgAKCR9dM4lw7Wu7p1OMHm7ESWi25gxwCgqUuL
RkTa6gZqUqUXTlM6h97nf30=
=bwi3
-END PGP SIGNATURE-

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Add TimeOffset and DateOffset typedefs

[Warren Turkal]

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 timestamp.c.
>
>  Applied with minor revisions.  I dropped DateOffset since it didn't seem
>  to be pulling its weight --- there was only one use and that was
>  probably better declared as TimeOffset anyway.  We can always add it
>  later if we really do need it.  Also I knocked over one or two other
>  places (in files beyond the ones you touched) where there was a
>  conditional declaration that could be eliminated.
>
>  There sure are a lot of #ifdef HAVE_INT64_TIMESTAMP's left, though,
>  aren't there :-(.  It looked like the next thing to think about was
>  how to unify the scale-dependent calculations.  We could make some
>  headway by defining a conversion constant that was either 100
>  or 1.0, but I'm worried about whether the C compiler is always smart
>  enough to optimize away a floating point multiplication or division
>  by 1.0 (there are at least some contexts where it *shouldn't* do
>  that, I think).  Might be better to make macros that either
>  multiply/divide by 100 or do nothing.
>
>  BTW, not sure if you're aware of this, but pgindent tends to add
>  and subtract blank lines around #if/#else/#endif commands in weird,
>  inconsistent ways.  If the vertical spacing seems a bit odd after
>  you've removed a conditional, feel free to fix it.  I fixed a number
>  of places like that in this patch.

Thanks for the info. I will look over the conversions. I have had them
in the back of my mind for a little while.

wt

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] serial arrays?

[Tom Lane]

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_seq" for serial 
column "foo.f1"
CREATE TABLE
regression=# \d foo
 Table "public.foo"
 Column |  Type   |Modifiers 
+-+--
 f1 | integer | not null default nextval('foo_f1_seq'::regclass)


Should we throw an error for this?  If not, what behavior would be
sane?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] timestamp datatype cleanup

[Warren Turkal]

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 make the int64 format the default?
>
>  This was gone over in great detail just recently ... didn't you see
>  that thread?

I actually hadnn't seen the resolution until just now. Thanks for
pointing it out.

wt

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Commit Fest (was Re: [HACKERS] Sort Refinement)

[Tom Lane]

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 adequately
reviewed or still needs some attention from the community.  If we think
the ball's entirely in Heikki's court on it, then we're done with it
until he comes back with a new version (or evidence showing it's good
as-is).

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal: new large object API

[Tom Lane]

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);  -- deletes large object with OID 173454
  
  INSERT INTO image (name, raster)
  VALUES ('beautiful image', lo_import('/etc/motd'));
+ 
+ INSERT INTO image (name, raster)  -- same as above, but specify OID to use
+ VALUES ('beautiful image', lo_import('/etc/motd', 68583));
  
  SELECT lo_export(image.raster, '/tmp/motd') FROM image
  WHERE name = 'beautiful image';
  


regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Commit Fest (was Re: [HACKERS] Sort Refinement)

[Tom Lane]

"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 are basically three types of work represented in the
current patch queue:

1. Actual patches that have some hope of being applied now, and if not
we are supposed to provide feedback about what's needed to fix them.

2. Design proposals that require further feedback.  I think the idea
of the commit fest is that we should provide such feedback now, so
that whoever is going to work on it can proceed.

3. Discussions that don't really need any further feedback right now,
but should be summarized as TODO entries.

The reason category 3 is represented is that this is after all
Bruce's personal work queue (you'll remember that I pushed him to
open it up before he'd finished cleaning out that type of entry).

Personally I've been trying to knock off items in category 1.
It'd be useful for people to go through some of the longer discussion
threads and try to categorize them as needing further discussion now
or being just TODO items.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Integer datetimes

[Tom Lane]

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 int64 datatypes will be the mainstream
usage, and the float implementation will be interesting only on very
old platforms or for very specialized applications.  I cannot see us
putting in the effort needed to refactor the code as two
simultaneously-available datatypes.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Commit Fest (was Re: [HACKERS] Sort Refinement)

[Andrew Dunstan]

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 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.




There is your CopyReadLineText speedup, but I think there are too many 
open questions on it, e.g.:


   * should we change the line-end detection mode in text (non-CSV)
 mode by looking for an LF preceded by an even number of
 backslashes, or some similar logic?
   * how do we decide when to use the memchr tests rather than char by
 char tests?
   * is there a more economical way to code the searcher? (although I
 could live with it for now)


So I suggest we take it out of the queue for now and kick it back to you.

cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [Fwd: Re: [PATCHES] 64-bit CommandIds]

[Tom Lane]

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 inside a transaction.
> the idea is to give users a chance to avoid that.
> touching XIDs does not make sense to me at all.

In view of the fact that 8.3 greatly reduced the CommandID consumption
of typical plpgsql code
http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php
I wonder whether the case for wider CIDs hasn't likewise taken a
major hit.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal: new large object API

[Tatsuo Ishii]

> > 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 longer.

Ok, here is the revised patch.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index: src/backend/libpq/be-fsstubs.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/be-fsstubs.c,v
retrieving revision 1.87
diff -c -r1.87 be-fsstubs.c
*** src/backend/libpq/be-fsstubs.c  1 Jan 2008 19:45:49 -   1.87
--- src/backend/libpq/be-fsstubs.c  21 Mar 2008 14:35:02 -
***
*** 79,84 
--- 79,85 
  
  static intnewLOfd(LargeObjectDesc *lobjCookie);
  static void deleteLOfd(int fd);
+ static Oid lo_import_internal(text *filename, Oid lobjOid);
  
  
  /*
***
*** 320,333 
  lo_import(PG_FUNCTION_ARGS)
  {
text   *filename = PG_GETARG_TEXT_P(0);
Filefd;
int nbytes,
tmp;
charbuf[BUFSIZE];
charfnamebuf[MAXPGPATH];
LargeObjectDesc *lobj;
!   Oid lobjOid;
! 
  #ifndef ALLOW_DANGEROUS_LO_FUNCTIONS
if (!superuser())
ereport(ERROR,
--- 321,354 
  lo_import(PG_FUNCTION_ARGS)
  {
text   *filename = PG_GETARG_TEXT_P(0);
+ 
+   PG_RETURN_OID(lo_import_internal(filename, InvalidOid));
+ }
+ 
+ /*
+  * lo_import_with_oid -
+  *  imports a file as an (inversion) large object specifying oid.
+  */
+ Datum
+ lo_import_with_oid(PG_FUNCTION_ARGS)
+ {
+   text   *filename = PG_GETARG_TEXT_P(0);
+   Oidoid = PG_GETARG_OID(1);
+ 
+   PG_RETURN_OID(lo_import_internal(filename, oid));
+ }
+ 
+ static Oid
+ lo_import_internal(text *filename, Oid lobjOid)
+ {
Filefd;
int nbytes,
tmp;
charbuf[BUFSIZE];
charfnamebuf[MAXPGPATH];
LargeObjectDesc *lobj;
!   Oid oid;
!   
  #ifndef ALLOW_DANGEROUS_LO_FUNCTIONS
if (!superuser())
ereport(ERROR,
***
*** 356,367 
/*
 * create an inversion object
 */
!   lobjOid = inv_create(InvalidOid);
  
/*
 * read in from the filesystem and write to the inversion object
 */
!   lobj = inv_open(lobjOid, INV_WRITE, fscxt);
  
while ((nbytes = FileRead(fd, buf, BUFSIZE)) > 0)
{
--- 377,388 
/*
 * create an inversion object
 */
!   oid = inv_create(lobjOid);
  
/*
 * read in from the filesystem and write to the inversion object
 */
!   lobj = inv_open(oid, INV_WRITE, fscxt);
  
while ((nbytes = FileRead(fd, buf, BUFSIZE)) > 0)
{
***
*** 378,384 
inv_close(lobj);
FileClose(fd);
  
!   PG_RETURN_OID(lobjOid);
  }
  
  /*
--- 399,405 
inv_close(lobj);
FileClose(fd);
  
!   return oid;
  }
  
  /*
Index: src/include/catalog/pg_proc.h
===
RCS file: /cvsroot/pgsql/src/include/catalog/pg_proc.h,v
retrieving revision 1.482
diff -c -r1.482 pg_proc.h
*** src/include/catalog/pg_proc.h   1 Jan 2008 19:45:57 -   1.482
--- src/include/catalog/pg_proc.h   21 Mar 2008 14:35:07 -
***
*** 1027,1032 
--- 1027,1034 
  
  DATA(insert OID = 764 (  lo_import   PGNSP PGUID 12 1 0 f f t f v 
1 26 "25" _null_ _null_ _null_  lo_import - _null_ _null_ ));
  DESCR("large object import");
+ DATA(insert OID = 767 (  lo_import   PGNSP PGUID 12 1 0 f f t f v 
2 26 "25 26" _null_ _null_ _null_   lo_import_with_oid - _null_ _null_ ));
+ DESCR("large object import");
  DATA(insert OID = 765 (  lo_export   PGNSP PGUID 12 1 0 f f t f v 
2 23 "26 25" _null_ _null_ _null_ lo_export - _null_ _null_ ));
  DESCR("large object export");
  
Index: src/include/catalog/catversion.h
===
RCS file: /cvsroot/pgsql/src/include/catalog/catversion.h,v
retrieving revision 1.442
diff -c -r1.442 catversion.h
*** src/include/catalog/catversion.h10 Mar 2008 13:53:35 -  1.442
--- src/include/catalog/catversion.h21 Mar 2008 14:35:07 -
***
*** 53,58 
   */
  
  /*mmddN */
! #define CATALOG_VERSION_NO200803101
  
  #endif
--- 53,58 
   */
  
  /*mmddN */
! #define CATALOG_VERSION_NO200803211
  
  #endif
Index: src/include/li

Re: Commit Fest (was Re: [HACKERS] Sort Refinement)

[Simon Riggs]

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 don't want to review
things that will be rejected for other reasons, so unless there is
clearer information I don't see how I can contribute further.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com 

  PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Commit Fest (was Re: [HACKERS] Sort Refinement)

[Bruce Momjian]

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 concept that I can think of.  Save 'em for later.
> > 
> > That's a fair reminder, thanks, I will do that.
> 
> I'm a bit in the dark about this Commit Fest, to be honest.
> 
> Is this the list of patches to be reviewed?
> http://wiki.postgresql.org/wiki/Todo:CommitFest

I don't think that list is complete.  The full archive is:

http://momjian.us/cgi-bin/pgpatches

Sorry, there is no summary.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Commit Fest (was Re: [HACKERS] Sort Refinement)

[Heikki Linnakangas]

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 concept that I can think of.  Save 'em for later.

That's a fair reminder, thanks, I will do that.


I'm a bit in the dark about this Commit Fest, to be honest.

Is this the list of patches to be reviewed?
http://wiki.postgresql.org/wiki/Todo:CommitFest

I was suspicious of that because it mentions "Minor changes to Recovery
related code" by Simon Riggs, which I'd already mentioned had been
committed more than 6 months ago.

ISTM that nobody has reviewed anything except you, Tom, from the list.
Is that true, or are there others working on reviews I can't see?

or maybe the patch list is this?
http://wiki.postgresql.org/wiki/Todo:PatchStatus


I'll review Tom Doran's and Dany DeBontridder's work. 


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 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.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Commit Fest

[Gregory Stark]

"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 direct undermining of the
>> > commit-fest concept that I can think of.  Save 'em for later.
>> 
>> That's a fair reminder, thanks, I will do that.
>
> I'm a bit in the dark about this Commit Fest, to be honest.
>
> Is this the list of patches to be reviewed?
> http://wiki.postgresql.org/wiki/Todo:CommitFest

That was labelled "experimental" and "in-progress". It was my attempt to dump
Bruces mailbox into the wiki. Unfortunately not enough information was present
in Bruce's pages to do that reasonably.

The "list" is at http://momjian.us/cgi-bin/pgpatches

It would be nice if we could remove the patches which have been reviewed or
applied from that list, but only Bruce can do that. Tom's berated Bruce once
for not focusing on the commitfest so I suspect that may happen soon.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com
  Ask me about EnterpriseDB's 24x7 Postgres support!

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Integer datetimes

[Zdenek Kotala]

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's hardly a one-liner.  If nothing else there are probably
multiple places in the documentation that need adjustment.



Does we keep same OID for this type? I prefer to redefine it as new type. It 
helps to determine which type is it for upgrade purpose. I think best solution 
is to have both code floating/int active and configure or initdb only perform 
correct linking in BKI file to preferred variant.


The result will be two datatypes datetime and timestamp_int or timestamp_float.
Or maybe better is to have two datatypes timestamp_int timestamp_float and one 
domain timestamp which points to preferred type.



Zdenek

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Commit Fest (was Re: [HACKERS] Sort Refinement)

[Simon Riggs]

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 I can think of.  Save 'em for later.
> 
> That's a fair reminder, thanks, I will do that.

I'm a bit in the dark about this Commit Fest, to be honest.

Is this the list of patches to be reviewed?
http://wiki.postgresql.org/wiki/Todo:CommitFest

I was suspicious of that because it mentions "Minor changes to Recovery
related code" by Simon Riggs, which I'd already mentioned had been
committed more than 6 months ago.

ISTM that nobody has reviewed anything except you, Tom, from the list.
Is that true, or are there others working on reviews I can't see?

or maybe the patch list is this?
http://wiki.postgresql.org/wiki/Todo:PatchStatus


I'll review Tom Doran's and Dany DeBontridder's work. 

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.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com 

  PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] How large file is really large - pathconf results

[Zdenek Kotala]

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 1024 for all platforms. If this values is correct then user on 
cygwin can have a
trouble. Please, could you test postgres with a long PATH?


thanks Zdenek

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers