On 10/13/06, Guillaume Lelarge <[EMAIL PROTECTED]> wrote:
Peter Eisentraut a écrit :
>
> There is an inconsistency here: 'IYYY' is the four-digit ISO year, 'IW'
> is the two-digit ISO week, but 'ID' would be the one-digit ISO
> day-of-the-week. I'm not sure we can fix that, but I wanted to poin
As discussed briefly on pgsql-hackers, the current psql \d command
does not make any distinction between enabled and disabled triggers.
The attached patch modifies psql's describeOneTableDetails() such that
triggers and disabled triggers are displayed as two separate footer
lists, for example:
T
On 11/7/06, Brendan Jurd <[EMAIL PROTECTED]> wrote:
As discussed briefly on pgsql-hackers, the current psql \d command
does not make any distinction between enabled and disabled triggers.
The attached patch modifies psql's describeOneTableDetails() such that
triggers and disabled t
On 11/9/06, Guillaume Lelarge <[EMAIL PROTECTED]> wrote:
Brendan Jurd a écrit :
> I will take a look at implementing 'isoyear' for extract(), and also
> start putting together a patch for the documentation. If Guillaume is
> still interested in adding the IDDD field to
On 11/11/06, Neil Conway <[EMAIL PROTECTED]> wrote:
The patch still leaks result7 circa line 1400 (CVS HEAD). I didn't look
closely, but you probably also leak result7 circa line 1209, if result6
is NULL.
New version of the patch attached (against CVS HEAD) that fixes these
two issues.
(Yeah
On 2/15/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> I don't think Oracle even has that. But personally I'd like to see
> >> errors for invalid pattern combinations.
>
> > What do we do with other invali
On 2/15/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Bruce Momjian wrote:
> Brendan Jurd wrote:
> > On 2/15/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > > Tom Lane wrote:
> > > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > &g
On 2/17/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Yes, it was: you now have two duplicate tests in timestamp.sql, and
no corresponding test in timestamptz.sql. It looks to me like the
submitter intended to be testing timestamp_tbl in the former file
and the same tests against timestamptz_tbl in th
On 2/17/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Thanks for the clarification. Would you have a look at the tests as
they are now and confirm that that's what you wanted?
Yes, the tests in HEAD right now are what I wanted. Although, while I
was in there I did notice a minor thing (anoth
This patch adds the default location for the DocBook DSSSL stylesheets
in gentoo's package system to the configure script.
The package in question is app-text/docbook-dsssl-stylesheets.
I'll understand if we don't want to include the location for every
single distribution under the sun, but figur
On 8/9/07, Neil Conway <[EMAIL PROTECTED]> wrote:
> FYI, patches should typically be submitted as context diffs. For the
> specific case of configure, you should submit patches against the source
> file (configure.in), not the generated file (configure).
Apologies. I haven't done much dev involvi
Just a minor doc upgrade. I've linked a couple of the more prominent
mentions of "escape string syntax" in Functions and Operators /
Pattern Matching back to the section on SQL string literals, which
explains how escape syntax works.
I considering linking all mentions of escape syntax, but though
On 8/7/05, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I propose to add an internal function gettime() that transparently
> returns the current system time, as a timestamptz with maximum
> precision.
>
Here's the patch.
The changes to pg_proc.h, ti
This patch to src/backend/executor/nodeFunctionscan.c is intended to
make life a little easier for people using row-returning functions, by
increasing the level of detail in the error messages thrown when
tupledesc_match fails.
Cheers
BJ
Index: src/backend/executor/nodeFunctionscan.c
=
Alvaro Herrera wrote:
On Wed, Jan 12, 2005 at 09:23:26AM +1100, Brendan Jurd wrote:
This patch to src/backend/executor/nodeFunctionscan.c is intended to
make life a little easier for people using row-returning functions, by
increasing the level of detail in the error messages thrown when
Brendan Jurd wrote:
Alvaro Herrera wrote:
On Wed, Jan 12, 2005 at 09:23:26AM +1100, Brendan Jurd wrote:
This patch to src/backend/executor/nodeFunctionscan.c is intended to
make life a little easier for people using row-returning functions,
by increasing the level of detail in the error
Tom Lane wrote:
Brendan Jurd <[EMAIL PROTECTED]> writes:
Thanks Alvaro, changes made and new patch attached.
I submitted this patch about 5 days ago and I haven't heard anything
since. I don't wish to be rude, but I'm not familiar with the
pgsql-patches etiquet
ed to leave that for another patch.
With thanks to Neil Conway for his assistance on IRC.
Cheers
BJ
On 9/15/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> This has been saved for the 8.4 release:
> Brendan Jurd wrote:
> > Hi hackers,
> >
> > I note that we cur
On 9/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> This seems rather pointless, since it's equivalent to
> quote_ident(schemaname) || '.' || quote_ident(relname).
Yes it is, and I brought that up in the OP:
I wrote:
> Clearly a DBA could just create this function himself in SQL (and it
> w
On 9/22/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> Ok, this removes what should be most if not all of the call sites where we're
> detoasting text or byteas. In particular it gets all the regexp/like functions
> and all the trim/pad functions. It also gets hashtext and hash_any.
Looks like the
On 9/29/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Has anyone every asked for this functionality?
I searched the list archives for previous mentions of the topic, and
didn't find any. So the answer to your question is "yes", but so far
it seems to be just me.
Cheers,
BJ
On 9/29/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I think we need more than one person's request to add this function.
Well, I don't expect it would get requested. Most DBAs would likely
look for the function in the docs, see it's not there and then just
implement it themselves. Obviously i
As discussed on -hackers, I'm trying to get rid of some redundant code
by creating a widely useful set of functions to convert between text
and C string in the backend.
The new extern functions, declared in include/utils/builtins.h and
defined in backend/utils/adt/varlena.c, are:
char * text_cstr
I noticed an editing error in the patch I originally submitted; it
defined the same debugging macro twice.
I've attached a fresh copy of the patch against the current HEAD with
the fix included.
Cheers,
BJ
On 8/11/07, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> Hello,
>
> As d
On 10/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Now that we've renamed the server binary to "postgres", what is the
> > status on use of the name "postmaster"? Is it now deprecated? A
Hi patchers,
Per discussion on -hackers, I've implemented a new internal function
quote_nullable, as an alternative to quote_literal. The difference is
that quote_nullable returns the text value 'NULL' on NULL input, which
is suitable for insertion into an SQL statement.
The idea is that when yo
On 10/12/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> I think you should add some examples to show how we would handle an
> INSERT or an UPDATE SET with quite_nullable() and a SELECT WHERE clause
> with quote_literal. The difference is a subtle one, which is why nobody
> mentioned it before, so it
On 10/15/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > I did make a version of the patch which has the pg_proc entries for
> > quote_literal and quote_nullable both pointing to the same internal
> > function. I thought this was a tidier solution, but it failed
> > regression test #5 in opr_sanity
On 10/12/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> I think you should add some examples to show how we would handle an
> INSERT or an UPDATE SET with quite_nullable() and a SELECT WHERE clause
> with quote_literal. The difference is a subtle one, which is why nobody
> mentioned it before, so it
On Nov 30, 2007 9:09 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> I'm sorry to suggest anything at this point, but... would it be less invasive
> if instead of requiring the immediate cast you created a special case in the
> array code to allow a placeholder object for "empty array of unknown typ
As discussed on -hackers, this patch allows the construction of an
empty array if an explicit cast to an array type is given (as in,
ARRAY[]::int[]).
postgres=# select array[]::int[];
array
---
{}
postgres=# select array[];
ERROR: no target type for empty array
HINT: Empty arrays must be
I've done up a patch per Tom's idea of combining the binary role
attributes into a single column.
Each attribute which differs from the default is listed on a separate
line, like so:
List of roles
Role name | Attributes | Member of
-++-
On Mon, Feb 25, 2008 at 5:05 PM, kenneth d'souza <[EMAIL PROTECTED]> wrote:
>
> Refrenced by :
> "htest_child_ctest_cust_id_fkey" IN public.htest_child(ctest_cust_id)
> REFERENCES htest(new_id)
> "htest_child1_ctest_cust_id_fkey" IN public.htest_child1(ctest_cust_id)
> REFERENCES htest(new_id)
ke to RFC again on Gregory's idea, and if that doesn't bear any
fruit I'd like to submit the patch as-is for review.
Regards,
BJ
On 01/12/2007, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On Nov 30, 2007 9:09 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> > I'
On 20/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> I started to look at applying this patch and immediately decided that
> I didn't like these names --- it's exceeding un-obvious which direction
> of conversion any one of the functions performs. Seems like every time
> you wanted to call on
On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>
> > As discussed on -hackers, this patch allows the construction of an
> > empty array if an explicit cast to an array type is given (as in,
> > A
On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> The code is now set up so that it can pass an entire field value
> through gettext(), but if gettext recognizes the strings "foo" and
> "bar" that doesn't mean it will do anything useful with "foo\nbar",
> which is what this patch would req
On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>
> > We can't just build the output table by hand like
> > describeOneTableDetails does? Admittedly it's kludgy, but it's not an
> > u
On 23/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Applied with some revisions to sync it with CVS HEAD --- primarily,
> since we now have a quote_literal(anyelement) function, it seemed
> important to add a quote_nullable(anyelement) variant. I also
> editorialized on the documentation ex
On 23/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Working through this patch now. I found one thing that seems to be
> a mistake (probably an overenthusiastic search&replace): the patch
> changes
> - {"iy", 2, dch_date, DCH_IY, TRUE},
> to
> + {"iyear", 2, DCH_IY, TRUE},
>
>
On 21/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > We can't just build the output table by hand like
> > describeOneTableDetails does? Admittedly it's kludgy, but it's not an
> > unprec
On 26/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> There are no textout/textin calls left, but I may have missed some
> places that were doing it the hard way with direct palloc/memcpy
> manipulations. It might be worth trolling all the VARDATA() references
> to see if any more are easily re
On 29/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> I intentionally didn't touch xml.c, nor anyplace that is not dealing
> in text, even if it happens to be binary-compatible with text.
>
Hmm, okay. My original submission did include a few such changes; for
example, in xml_in and xml_out_intern
On 31/03/2008, Gregory Stark <[EMAIL PROTECTED]> wrote:
> It might be cute to see if the pattern matches any user functions and if not
> try again with system functions. So you would still get results if you did
> "\df rtrim" for example.
>
Nice idea. +1 for this behaviour.
Cheers,
BJ
--
Se
On 01/04/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> ... That means
> there'd be no way to replicate the all-functions-of-both-types behavior
> that has been the default in every prior release.
> \dfS-> sys functions only
> \dfU-> user functions only
> \dfSU ->
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/04/2008, Tom Lane wrote:
> David Fetter writes:
> > When we have a bad default--and I'd argue that for anyone not
> > developing PostgreSQL itself, showing system functions is a bad
> > default--we should change it to something sane.
>
> I d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2008, Greg Sabino Mullane wrote:
> > \df Lists all user functions
> > \df [pattern] Lists both system and user functions matching [pattern]
> > \df * Lists all system and user functions
>
> I don't like this for two reasons: the items retu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Am Donnerstag, 3. April 2008 schrieb Gregory Stark:
>
> > #= \oldd
> >
> > #= \old
> > #= select 'where is all my output going?'
> > #= select 'what happened to my ldd file?'
>
psql allows you to omit the space between the command and argument?
Hi there,
Noticed a typo in the root README file. Patch below.
Regards,
BJ
--- a/README
+++ b/README
@@ -20,7 +20,7 @@ PHP - http://www.php.net
Python - http://www.initd.org/
Ruby - http://ruby.scripting.ca/postgres/
-Other language binding are available from a variety of contributing
+Other
On Mon, Mar 31, 2008 at 3:50 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "kenneth d'souza" <[EMAIL PROTECTED]> writes:
> > With reference to the post
> http://archives.postgresql.org/pgsql-patches/2008-02/msg00104.phpand as
> stated by -hackers and -patchers, I am submitting the diff -c output as
On Sun, Mar 30, 2008 at 9:39 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> On 25/03/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > > This makes me wonder whether print.c could offer something a bit mo
On Tue, Mar 25, 2008 at 2:41 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > This makes me wonder whether print.c could offer something a bit more
> > helpful to callers wishing to DIY a table; we could have a
> &
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Apr 14, 2008 at 4:44 PM, kenneth d'souza wrote:
>
> Hi Brendan,
> Your observation is correct.
>
> The indentation is deliberate. The reason is that the (result7,i,3) starts
> with the word "FOREIGN KEY ". I am using the details that follow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Apr 14, 2008 at 11:42 PM, Tom Lane wrote:
> "Brendan Jurd" writes:
> > Sorry Kenneth, I didn't quite follow your explanation. How does the
> > position of "FOREIGN KEY " affect the indentation at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Mar 21, 2008 at 7:47 AM, Tom Lane wrote:
> I didn't do anything about removing A_Const's typename field, but I'm
> thinking that would be a good cleanup patch.
>
Here's my attempt to remove the typename field from A_Const. There
were a few
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Apr 13, 2008 at 6:11 PM, Brendan Jurd wrote:
> I've written a patch which implements the same \du behaviour as my
> previous patch, but using the new printTable API
New versions of this patch, including changes made to the pri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Apr 14, 2008 at 6:03 AM, Alvaro Herrera wrote:
> Looks cool -- on a first read, I think you should add some more code
> comments at the top of each function specifying whether the texts need
> to be translated by the caller or done by the f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Mar 29, 2008 at 5:40 AM, Brendan Jurd wrote:
> On 29/03/2008, Tom Lane wrote:
> > I intentionally didn't touch xml.c, nor anyplace that is not dealing
> > in text, even
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 16, 2008 at 10:00 PM, kenneth d'souza wrote:
> However,Why does the word "FOREIGN KEY" appear in the last line of your
> output. My original patch had the output like this.
> Referenced by:
> "bar_foo_fkey" IN public.bar(foo) REFERENCE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 1:16 AM, Tom Lane wrote:
> "Brendan Jurd" writes:
>
> >> If we don't want to meddle with xmltype/bytea/VarChar at all, we'll
> >> have to revert those changes, and I'll have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 7:27 AM, Alvaro Herrera wrote:
> Brendan Jurd escribió:
>
> > The second version of the patch is attached.
>
> Thanks. I looked the patch over and did some minor changes. Modified
> version attached.
r looking, and there's a
symmetry in having the "first item" and "last item" pointers be the
same type.
If there's some technical reason that integers would be better, I'll
all ears, but from an aesthetic/code readability perspective I like
the pointer.
> > B
Hi hackers,
It occurred to me that psql's \z command could benefit from the
addition of some newlines. With any more than one grantee per object,
the output of \z rapidly becomes extremely wide, and very hard to
read.
I'd like to split the output onto one line per grantee. So, instead of this:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 18, 2008 at 2:37 AM, Tom Lane wrote:
> The function names in the patch need schema-qualification in case
> pg_catalog is not first in the search path.
>
Ah, yes. I should have seen that. Thanks Tom.
New version attached with schema-q
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
The attached patch resolves the bug reported by Kaloyan Iliev [1] on -general.
The problem occurred when executing ALTER TABLE ... ADD COLUMN ...
PRIMARY KEY with no default clause, on a table with rows already
present. The NOT NULL constraint w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, May 4, 2008 at 10:55 AM, Tom Lane wrote:
> Andrew Dunstan writes:
> > Wouldn't this expression:
> > pg_catalog.array_to_string(c.relacl, chr(10))
> > be better expressed as
> > pg_catalog.array_to_string(c.relacl, E'\n')
>
>
Hi guys,
Here's the latest version of the printTable API. This version is
against the current HEAD and merges in the changes made by the
recently committed psql wrap patch.
This version also includes Alvaro's fix for the issue of pg_strdup not
being available to programs in scripts/ (as quoted b
Hi all,
Well, it's been a long time coming, but I've finally got a patch to
improve the error handling of to_date() and to_timestamp(), as
previously discussed on -hackers. [1][2]
The patch is against HEAD, and compiles cleanly and passes all
regression tests on gentoo amd64.
I did some testing
Hi folks,
As discussed on -hackers [1], here is a patch to add a pg_typeof()
builtin function to core.
The function accepts one argument (type "any") and returns the regtype
of that argument. This can be helpful in various circumstances,
including troubleshooting cast/coercion behaviour in a que
69 matches
Mail list logo
