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 this
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 elog
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 tim
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:
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.
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 ...
> Why ru
[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 p
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 gua
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 behav
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, 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 p
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 applicatio
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 environm
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, there
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() retu
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: P
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
ups
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
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','a"b\c'];
andrew
19 matches
Mail list logo
