The attached patch (submitted for comment) is somewhat adapted from one
submitted last October. This allows returning a perl array where a
postgres array is expected.
example:
andrew=# create function blurfl() returns text[] language plperl as $$
andrew$# return ['a','b','c','ab\c'];
The attached patch modifies initdb to create a default database called
'postgres' when the cluster is initialised. Documentation updates are
included, including updates to relevant examples to encourage users to
use this database in place of template1. I have not modified utilities
like createuser
Neil Conway [EMAIL PROTECTED] writes:
This patch makes various cosmetic improvements to the timezone code:
remove the use of the register qualifier, make some function declaration
syntax a bit more consistent, etc.
I think mostly what you are doing here is causing code drift from the
Attached is an updated version of this patch which /does/ update
utilities to use the postgres database by default, per comments on
-hackers.
Regards, Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Page
Sent: 20 June 2005 13:07
To:
On Mon, Jun 20, 2005 at 05:06:32AM -0400, Andrew Dunstan wrote:
The attached patch (submitted for comment) is somewhat adapted from one
submitted last October. This allows returning a perl array where a
postgres array is expected.
example:
andrew=# create function blurfl() returns
David Fetter wrote:
In src/backend/utils/adt/arrayfuncs.c there are direct
array-manipulation functions.
And in other places - I had already found that stuff :-) . But a worked
example would help. If it's not available I'll muddle through some time.
In the perlapi docs for perl,
Tom has applied this patch. Thanks.
---
Simon Riggs wrote:
I enclose a complete patch for avoiding WAL usage for CREATE TABLE AS
SELECT, when not in archive mode (PITR). The main use case for this is
large BI
Simon Riggs [EMAIL PROTECTED] writes:
I enclose a complete patch for avoiding WAL usage for CREATE TABLE AS
SELECT, when not in archive mode (PITR). The main use case for this is
large BI environments that create summary tables or prejoined tables,
though there are many general applications.
On Mon, 2005-06-20 at 14:50 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I enclose a complete patch for avoiding WAL usage for CREATE TABLE AS
SELECT, when not in archive mode (PITR). The main use case for this is
large BI environments that create summary tables or prejoined
On Mon, 2005-06-20 at 17:09 -0400, Alvaro Herrera wrote:
On Mon, Jun 20, 2005 at 09:55:12PM +0100, Simon Riggs wrote:
I put those changes in mainly for COPY. If you don't make any request at
all to FSM then a relation never gets to the MRU relation FSM list. I
agree that it is not
On Mon, Jun 20, 2005 at 09:55:12PM +0100, Simon Riggs wrote:
I put those changes in mainly for COPY. If you don't make any request at
all to FSM then a relation never gets to the MRU relation FSM list. I
agree that it is not strictly necessary, but leaving it off would be a
change in
Tom Lane wrote:
I think mostly what you are doing here is causing code drift from the
upstream zic code. I don't think that's a very good idea, since we
do need to be able to track and apply bug fixes from them from time
to time ...
Why run pgindent on the timezone code, then? That seems
[EMAIL PROTECTED] writes:
Below were the communications between Tom and me before I implemented this
project. I just did what he asked me to do.
Part of it, maybe --- my point was that without any support in (at
least) plpgsql, the feature is of only academic interest. There's not
a lot of
Tom Lane wrote:
Well, it's certainly hopeless to expect patch to fix it :-(. But the
further the code drifts the harder it gets to compare manually.
Sure, but I don't see how removing a few register qualifiers and so
forth is going to make the slightest difference to a manual comparison.
If
The Coverity tool picked up some rather bizarre code in _tarGetHeader in
pg_backup_tar.c:
(1) The code doesn't initialize `sum', so the initial does the checksum
match? test is wrong.
(2) The loop that is intended to check for a null block just checks
the first byte of the tar block 512
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think mostly what you are doing here is causing code drift from the
upstream zic code. I don't think that's a very good idea, since we
do need to be able to track and apply bug fixes from them from time
to time ...
I did a few cleanups on the last patch. Please examine this one instead.
The changes are:
1. Add documentation for pg_datum_length builtin.
2. Correct some typos in the code comments.
3. Move the code in toastfuncs.c to varlena.c as it is probably the
correct place.
4. Use ereport instead of
Hello,
This is my first post to this list.
Sorry if my english it's not so good. It's not my native language.
I'm interrested to now if someone think that having a feature like
'thousands comma delimited numeric formatting' in psql it's a
usefull thing.
I've made a patch for psql that adds
18 matches
Mail list logo
