Ron Mayer wrote:
Ron Mayer wrote:
Ron Mayer wrote:
> Tom Lane wrote:
>> In fact, given that we are now
>> somewhat SQL-compliant on interval input, a GUC that selected
>> PG traditional, SQL-standard, or ISO 8601 interval output format
seems
>> like it could be a good idea.
Attached are
attached is a patch which enables plpython to recognize function with
multiple OUT params as returning a record
py=# create or replace function addsub( in i1 int, in i2 int,
py=# out o1 int, out o2 int) as
py=# $$
py$# return i1 + i2, i1-i2
py$# $$ language plpythonu;
CREATE FUNCTION
py=#
p
Bruce Momjian wrote:
Robert Haas wrote:
One other random note - I don't believe there has been a new version
of the column-level permissions patch that Stephen Frost was working
on since the last commitfest. Unless someone disagrees with Markus
Wanner's conclusion that it wasn't ready for commi
Ron Mayer wrote:
Ron Mayer wrote:
> Tom Lane wrote:
>> In fact, given that we are now
>> somewhat SQL-compliant on interval input, a GUC that selected
>> PG traditional, SQL-standard, or ISO 8601 interval output format seems
>> like it could be a good idea.
Attached are updated versions of
Ron Mayer wrote:
> Tom Lane wrote:
>> In fact, given that we are now
>> somewhat SQL-compliant on interval input, a GUC that selected
>> PG traditional, SQL-standard, or ISO 8601 interval output format seems
>> like it could be a good idea.
Attached are updated versions of the Interval patches (S
On Thu, 2008-10-30 at 10:13 +, Simon Riggs wrote:
> On Tue, 2008-10-21 at 15:06 +0100, Simon Riggs wrote:
>
> > We can't augment the commit/abort messages because
> > we must cater for non-transactional invalidations also, plus commit
> > xlrecs are already complex enough. So we log invalidat
On Wed, 2008-10-29 at 23:12 -0400, Tom Lane wrote:
> Earlier today I had a different thought about how to sort things early
> in the fest. I think that there is a strong temptation to finish off
> the "simple" patches quickly so as to reduce the size of the list ---
> I know I've done that and I
Robert Haas wrote:
> One other random note - I don't believe there has been a new version
> of the column-level permissions patch that Stephen Frost was working
> on since the last commitfest. Unless someone disagrees with Markus
> Wanner's conclusion that it wasn't ready for commit at that point,
Hi all In-place upgrade fans,
David Fetter (thanks) configured Git repository for me and I put all patches
into it. Currently you can start play (of course not on production database :-).
Current version of in-place upgrade supports only select with "small" limitation
- indexscan on index w
On Fri, 2008-10-31 at 13:14 -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > archive_mode = on disables the optimization to skip WAL-logging when
> > loading into a new table that was created in the same transaction.
>
> ... and affects a whole bunch of other behavior
Hi Nikhil,
Here are a couple of questions:
- How do you ALTER the table to repartition it?
- The trigger function for inserts could be improved by using ELSE
instead of independent IFs. This would ensure that the row is inserted
in at most 1 partition. The last ELSE should raise an exception if
2008/11/1 Tom Lane <[EMAIL PROTECTED]>:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>>> 2008/11/1 David Fetter <[EMAIL PROTECTED]>:
>>> I've ever sent a patch over 100k and failed. Actually how much is the
>>> limitation of the patch size? And if the
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> 2008/11/1 David Fetter <[EMAIL PROTECTED]>:
>> I've ever sent a patch over 100k and failed. Actually how much is the
>> limitation of the patch size? And if the patch is too huge, is it
>> better to split th
On Fri, Oct 31, 2008 at 01:37:00PM -0400, Robert Haas wrote:
> > Please find attached a patch which works in PL/Perl, the work having
> > been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
> > this would be generally surface-able to SQL, though. Any ideas?
> >
> > CREATE OR REPLAC
>>> Brad Nicholson <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-10-31 at 17:38 +0200, Peter Eisentraut wrote:
>> Tom Lane wrote:
>> > Why is this worth spending effort on?
>>
>> The addition of archive_mode changeable with restart only was a
>> significant loss of usability going from 8.2 to 8.3, i
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> * Return the count of tuples processed, probably as a long since that's
>> what the input limit-count is. There are potential overflow issues with
>> this definition on 32-bit machines, though that's not going to a
> Please find attached a patch which works in PL/Perl, the work having
> been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
> this would be generally surface-able to SQL, though. Any ideas?
>
> CREATE OR REPLACE FUNCTION show_qual()
> RETURNS TEXT
> LANGUAGE plperl
> AS $$
> retur
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> 2008/11/1 David Fetter <[EMAIL PROTECTED]>:
>> On Fri, Oct 31, 2008 at 01:00:38PM -0300, Alvaro Herrera wrote:
>>> Hitoshi Harada escribió:
>>>
>>> > [Patch itself]
>>>
On Fri, 2008-10-31 at 17:38 +0200, Peter Eisentraut wrote:
> Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> Objections?
> >
> > Why is this worth spending effort on?
>
> The addition of archive_mode changeable with restart only was a
> significant loss of usability going from 8
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> archive_mode = on disables the optimization to skip WAL-logging when
> loading into a new table that was created in the same transaction.
... and affects a whole bunch of other behaviors too, in processes all
across the database that could not pos
Tom Lane <[EMAIL PROTECTED]> writes:
> * Return the count of tuples processed, probably as a long since that's
> what the input limit-count is. There are potential overflow issues with
> this definition on 32-bit machines, though that's not going to affect
> functions.c since it passes a limit of
2008/11/1 David Fetter <[EMAIL PROTECTED]>:
> On Fri, Oct 31, 2008 at 01:00:38PM -0300, Alvaro Herrera wrote:
>> Hitoshi Harada escribió:
>>
>> > [Patch itself]
>> > http://umitanuki.net/pgsql/wfv08/window_functions.patch.20081031.gz
>>
>> Please
We'd like to improve usefulness of a new multicolumn feature of GIN index (
already in CVS HEAD ), which is currently a bit limited because of lack of GIN
support for most data types. For example, it'd be very useful to combine native
GIN-supported data types, like text search, hstore, arrays w
Currently, the result of ExecutorRun is typically NULL, but if it's
executing a SELECT and you pass a limiting count and the SELECT stops
early because of that limit, then you get back a TupleTableSlot
containing the last tuple processed.
This is pretty ugly.
There is only one call site that even
>>> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
>> It doesn't log anything extra when archive_mode is on?
>
> Depends on your logging level.
I guess my question wasn't clear -- I meant into the Write-Ahead Log
(WAL) files.
-Kevin
--
Sent via pgsql-hackers mailing li
Joshua D. Drake wrote:
Kevin Grittner wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
It certainly makes more sense to do this:
archive_mode = off
archive_command = '/archive/command/used/during/snapshot/backups'
I could live with diddling the command to control archiving.
It doesn't
On Fri, 2008-10-31 at 17:49 +0200, Martin Pihlak wrote:
> Here is an updated patch. I'm also submitting this to November Commitfest -
> I believe it is possible to get this into shape for 8.4. This is still a WIP
> but I really need a review before moving on with the syntax, pg_dump support
> etc.
Hi all,
I am having a project in Postgres where I had modified code in
gram.y...I have added new command along with grammer and returning
list of parse nodes as opposed to single node inside actions
blockI want to process each of them in postgres.c file...But, I
couldn't find any difference i
With the attached patch, SQL functions support returning the results of
INSERT/UPDATE/DELETE RETURNING clauses. An INSERT/UPDATE/DELETE
statement is always executed to completion before returning (including
firing any related triggers or rules), so we always materialize the
RETURNING output. When
Kevin Grittner wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
It certainly makes more sense to do this:
archive_mode = off
archive_command = '/archive/command/used/during/snapshot/backups'
I could live with diddling the command to control archiving.
It doesn't log anything extra when
>>> "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> It certainly makes more sense to do this:
>
> archive_mode = on
> pg_ctl reload
>
> archive_mode = off
> pg_ctl reload
>
> versus
>
> archive_command = '/path/to/really/long/archive/string'
> pg_ctl reload
>
> archive_command = '/bin/true'
>
Hitoshi Harada escribió:
> [Patch itself]
> http://umitanuki.net/pgsql/wfv08/window_functions.patch.20081031.gz
Please send the patch to the pgsql-hackers list too. That way we will
have the patch around, even if the site above goes away in a few years.
--
Alvaro H
Folks,
My old personal mail server is on its last legs. I'm migrating to a
new mail server (running Archiveopteryx, yaaay) this weekend. However,
that will mean interruptions in mail sent to [EMAIL PROTECTED], and may
even result in my getting kicked off some lists.
If you need to reach me abou
Here is an updated patch. I'm also submitting this to November Commitfest -
I believe it is possible to get this into shape for 8.4. This is still a WIP
but I really need a review before moving on with the syntax, pg_dump support
etc.
Currently the system catalogs and user accessible connection lo
Peter Eisentraut wrote:
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
Objections?
Why is this worth spending effort on?
The addition of archive_mode changeable with restart only was a
significant loss of usability going from 8.2 to 8.3, in the minds of
many people.
It certainl
Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
Objections?
Why is this worth spending effort on?
The addition of archive_mode changeable with restart only was a
significant loss of usability going from 8.2 to 8.3, in the minds of
many people.
--
Sent via pgsql-hackers mailing l
Simon Riggs <[EMAIL PROTECTED]> writes:
> Objections?
Why is this worth spending effort on? I doubt that your sketch is
correct/complete anyway (you at least neglected to describe starting
and stopping the archiver, as well as how it knows where to start
archiving).
regar
>>> Simon Riggs <[EMAIL PROTECTED]> wrote:
> Currently we enable archive_mode only at server start. The reason
for
> this was to protect against people enabling archive_mode half way
> through somebody else running a bulk load without WAL and then having
an
> incomplete backup.
>
> All we need to
Currently we enable archive_mode only at server start. The reason for
this was to protect against people enabling archive_mode half way
through somebody else running a bulk load without WAL and then having an
incomplete backup.
All we need to do is this:
* When we change archive_mode to "on" get
>>> Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Here is an implementation of distinct types, known from SQL99 and
> beyond. They are like domains, except that they don't have defaults
or
> constraints and they do not allow implicit casting to their base
type.
> The latter aspect is what make
Hi,
> > > >
>> > > >> Thanks for taking a look. But if I am not mistaken Gavin and co.
>> are
>> > working
>> > > >> on a much exhaustive proposal. In light of that maybe this patch
>> might
>> > not
>> > > >> be needed in the first place?
>> > > >>
>> > > >> I will wait for discussion and a subs
On Wed, Oct 29, 2008 at 09:40:00AM -0700, David Fetter wrote:
> Folks,
>
> Please find enclosed a WIP patch to add the ability for functions to
> see the qualifiers of the query in which they're called. It's not
> working just yet, and I'm not sure how best to get it working, but I'd
> like to se
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I'm not sure but I think we can store composite types without typid and
> typmod
No, we can't. At least, tuple header structure is not the reason why not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacke
I have completed my work on the patch for commit fest.
[Design Doc]
http://umitanuki.net/pgsql/wfv08/design.html
[Patch itself]
http://umitanuki.net/pgsql/wfv08/window_functions.patch.20081031.gz
[Git repository]
http://git.postgresql.org/git/~davidfetter/window_functions/.git
All compiler
Fujii Masao wrote:
Attached is a patch for a synchronous log-shipping replication which
was discussed just a month ago. I would like you to review this patch
in Nov commit fest.
Here's some first quick comments:
AFAICS, there's no security, at all. Anyone that can log in, can become
a WAL sen
Here is an implementation of distinct types, known from SQL99 and
beyond. They are like domains, except that they don't have defaults or
constraints and they do not allow implicit casting to their base type.
The latter aspect is what makes them distinct types. They are useful to
create more t
On Thu, 2008-10-30 at 22:46 -0400, Robert Haas wrote:
> > You should try profiling the patch. You can count the invocations of the
> > buffer access routines to check its all working in the right ratios.
>
> *goes and learns how to do profile PostgreSQL*
>
> OK, that was a good suggestion. It l
Here is an implementation of distinct types, known from SQL99 and
beyond. They are like domains, except that they don't have defaults or
constraints and they do not allow implicit casting to their base type.
The latter aspect is what makes them distinct types. They are useful to
create more type
2008/10/31 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> RETURN QUERY should be implemented for lazy execution model. And it
>> should be fast and not to much dificult.
>
> Really? Consider what happens if it's inside a loop, or an exception
> block, or any other n
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> RETURN QUERY should be implemented for lazy execution model. And it
> should be fast and not to much dificult.
Really? Consider what happens if it's inside a loop, or an exception
block, or any other nesting construct.
regards
Reworked version of fast insertion patch for GIN.
* shiftList does LockBufferForCleanup, which means that it can be blocked
for an indefinitely long time by a concurrent scan, and since it's
holding
exclusive lock on metapage no new scans or insertions can start
meanwhile.
This is not only hor
Fujii Masao wrote:
And, there are some problems in this patch;
* This patch is somewhat big, though it should be subdivided for
review.
* Source code comments and documents are insufficient.
Is it against the rule of commit fest to add such a status patch
into review-queue? If so, I would a
On Thu, Oct 30, 2008 at 11:19:15PM -0700, Jeff Davis wrote:
> If there are potential problems with the standard
> (where we don't want to implement a violation), we should just do
> array_accum(). If not, we might as well do the standard array_agg(),
> perhaps without the ORDER BY clause.
I've wan
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
1) HeapTupleHeader modification
typedef struct HeapTupleFields
{
TransactionId t_xmin; /* inserting xact ID */
TransactionId t_xmax; /* deleting or locking xact ID */
union
Hi
Attached is a patch for a synchronous log-shipping replication which
was discussed just a month ago. I would like you to review this patch
in Nov commit fest.
The outline of this patch is as follow;
1) Walsender
This is new process to focus on sending xlog through the position
which a backen
Gregory Stark napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
3) TOAST modification
a) TOAST table per attribute
b) replace chunk id with offset+variable chunk size
c) add column identification into first chunk
Thats all. I think infomask/infomask2 shuffle flag should be done. TOAST
* Greg Stark:
> Wal logged changes are safe because of full_page_writes. Hint bits are
> safe because either the old or the new value will be on disk and we
> don't care which.
Is this really true with all disks? IBM's DTLA disks didn't behave
that way (an interrupted write could zero a sector),
I've updated my patches, it contains a few bugfixes.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1168.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1168.patch
[3/6]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4deve
2008/10/30 Robert Haas <[EMAIL PROTECTED]>:
>> With session variables we could implement srf function in plpgsql like
>> current C srf function. Like
>>
>> create or replace function foo()
>> returns record as $$
>> #option with_srf_context(datatype of srf context)
>> begin
>> return row(...)
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
Tom Lane <[EMAIL PROTECTED]> writes:
... 3b sounds good until you
reflect that a genuinely variable chunk size would preclude random
access to sub-ranges of a toast value.
Hm, Heikki had me convinced it wouldn't but now that I try t
60 matches
Mail list logo
