On 08/03/2008, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> I think we'll have more success convincing patch authors to update a
> wiki page, than we'll have to convince reviewers to do so. I know that's
> true at least for me. If I want people to review my patch, I'm ready to
> sing and dan
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 Wed, Feb 27, 2008 at 2:29 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> > You could just pull up a psql session and do a "select
> > pg_func_def(regproc);" and there you go, one fully formed CREATE
> > FUNCTION statement.
>
> \df+ function(type)
>
Sure, if your idea of a good time is lo
On Tue, Feb 26, 2008 at 12:48 AM, David BOURIAUD
<[EMAIL PROTECTED]> wrote:
> I haven't found any option to dump any user-defined function stored in a
> database, unless doing a pg_dump -D -s database, but so far one would get the
> definitions of the tables, the permissions, the triggers, and s
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 Fri, Feb 15, 2008 at 12:19 PM, Decibel! <[EMAIL PROTECTED]> wrote:
> On Feb 14, 2008, at 7:27 AM, Alvaro Herrera wrote:
> > Attributes: S -- superuser
> > R -- create role
> > D -- create database
> > I -- inherit
>
>
> Can we add something similar to the bot
On Fri, Feb 15, 2008 at 10:50 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > What about connection limit? I suppose we could combine it into the
> > privileges column, and refrain from displaying anything for "
On Fri, Feb 15, 2008 at 3:42 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Now that psql prints multiline field values nicely, maybe it'd work
> to fold all the boolean attributes into one column. I'm imagining
> something like
>
> Role name | Privileges | Member of
> --+-+--
Hello hackers,
psql's \du command currently does not list the INHERIT role attribute.
It does show the other privilege attributes (superuser, create role,
create db), and INHERIT seems like the kind of thing a user
executing\du would want to know.
I'd like to add it to \du. The downside is that
On Feb 13, 2008 10:45 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> For the patches lists I need to take sometimes entire threads, sometimes
> groups of comments, and store them in a format so people can review them
> as a digest. And I want to allow comments on these items, and ideally
> allow m
Though to be safe you should be quoting MT and ST with quote_ident()
before putting them into a dynamic statement.
Cheers
BJ
On Feb 12, 2008 4:38 PM, Brett McBride <[EMAIL PROTECTED]> wrote:
> you could do this with 'execute' like so:
>
> execute 'select count(*) into count1 from ' || MT || ','
On Feb 10, 2008 8:58 AM, Jan Wieck <[EMAIL PROTECTED]> wrote:
> I wonder if the efforts to provide mirrors for many different systems can
> hurt later down the road. It is pretty obvious that amost every current
> system has options to convert from or to mirror a CVS repository. But what if
> we
On Feb 10, 2008 3:50 AM, Patrick Welche <[EMAIL PROTECTED]> wrote:
> NOTICE: (1,two,"Sat 09 Feb 16:47:44.514503 2008")
> INSERT 0 0
>
I think what you're seeing is the syntax for row literals.
You can get an idea of how it looks without having to write trigger
functions, e.g.:
> select row(1, '
On Feb 8, 2008 10:29 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Am Freitag, 8. Februar 2008 schrieb Markus Bertheau:
> > Maybe the existing SVN, git and other mirrors could just become more
> > official and supported in the sense that users can rely on them to be
> > updated often enough?
>
This all sounds very promising.
On Feb 6, 2008 7:56 PM, Dave Page <[EMAIL PROTECTED]> wrote:
> Each fest will continue until all patches in the queue have
> either been committed to the CVS repository, returned to the author
> for additional work, or rejected outright, and until that has
> happene
On Jan 26, 2008 8:14 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> This two-faced personality is just why we're facing this problem. It looks to
> users like DML but it under the hood it behaves just like DDL.
>
Agreed that it looks like DML. Speaking as a user, I came away from
the documentatio
On Jan 18, 2008 3:19 AM, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> > Isn't there a danger of syntactical conflict with the SQL SELECT ... CASE
> > statement?
>
> no, isn't. SELECT CASE can be only in expression .. inside SQL
> statement, but PL/SQL CASE is PL statement. These are two different
> w
On Jan 17, 2008 8:22 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan wrote:
> > Tom Lane wrote:
> > > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > >
> > >> A further example shows that to_date seems to have little error checking
> > >> altogether:
> > TODO list item?
>
> We have
On Jan 10, 2008 5:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> The spec's approach to datetime operations in general is almost totally
> brain-dead, and so you won't find a lot of support around here for hewing
> to the straight-and-narrow-spec-compliance approach. If they have not
> even heard of
On Jan 10, 2008 3:33 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> 1 month is deemed equal to 30 days, 1 day is deemed equal to 24 hours
> (although for some reason we ignore the issue of years vs. days).
>
Sorry, a correction. The issue of years vs. days isn't ignored. A
ye
On Jan 10, 2008 2:17 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> You'd have to define exactly what that means, which seems a little
> tricky for incommensurate intervals. For instance what is the
> result of '1 month' / '1 day' ?
>
Postgres has already made such definitions, to allow direct
interva
On Dec 23, 2007 1:25 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I have written documentation for this item:
>
> http://momjian.us/tmp/pgsql/server-shutdown.html#SERVER-SPOOFING
>
> Comments?
I thought the content made sense, but the location didn't. I wouldn't
expect to find instructi
On Dec 23, 2007 12:20 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Gurjeet Singh wrote:
> > On Dec 22, 2007 6:25 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > This way, if the attacker has control of even one interface (and
> > optionally the local socket) that the clients are expected to
On Dec 10, 2007 10:39 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
I like the realease notes intro. You may have already picked up on
these, but a couple typos:
> A names appearing next to an item represents the major developer for
> that item. Of course all changes involve comm
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
On Nov 30, 2007 11:10 AM, Andreas 'ads' Scherbaum <[EMAIL PROTECTED]> wrote:
> i would also like to test another Beta, if we do something about this
> problem:
>
> http://archives.postgresql.org/pgsql-hackers/2007-11/msg00960.php
Hi Andreas,
Tom's already committed the quote_literal(anyelement) f
Hi folks,
The patch is coming along nicely now. I do have a couple of questions
about the implementation in transformArrayExpr though.
1) How should we determine whether the array is multidimensional if we
know the type in advance?
Currently, transformArrayExpr uses the results of its sear
On Nov 28, 2007 9:49 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I had a bit of a dig into this. A_Const->typename gets set directly
> > by the parse paths for "INTERVAL [(int)] string [interval range]". In
> > fact, as far as I can tell that's the _only_ place A_Const->typename
> > gets used at
On Nov 28, 2007 4:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Now I'm thinking I leave the grammar rules alone (apart from making it
> > legal to specify an empty list of elements), and instead push the
On Nov 28, 2007 2:56 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I wonder whether we are also interested in catching CAST(), e.g.:
>
> > CAST(ARRAY[] AS text[])
>
> I think you'll find that it's just about impossible to not handle both,
> because they look the same after the grammar gets done.
Tha
So far I've only considered the '::' cast syntax suggested in the
original proposal, e.g.:
ARRAY[]::text[]
I wonder whether we are also interested in catching CAST(), e.g.:
CAST(ARRAY[] AS text[])
I'm personally okay with leaving it at support for '::', but
admittedly I am heavily biased toward
On Nov 27, 2007 8:04 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > ... So
> > unfortunately I can't just add a TypeName member to ArrayExpr.
>
> That would be quite the wrong thing to do anyway, since ArrayE
Quoting Tom, from the previous thread linked by Martijn:
> It could be pretty ugly, because type assignment normally proceeds
> bottom-up :-(. What you might have to do is make the raw grammar
> representation of ARRAY[] work like A_Const does, ie, there's a
> slot to plug in a typecast. That's
On Nov 26, 2007 3:58 AM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 26, 2007 at 03:51:37AM +1100, Brendan Jurd wrote:
> > I noticed in the 8.3 release notes that ARRAY(SELECT ...) now returns
> > an empty array if there are no rows returned by the subque
On Nov 26, 2007 5:23 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > So, I wonder why we don't just adapt the internal function to take
> > anyelement?
>
> The main argument against is the "slippery slop
On Nov 25, 2007 11:51 PM, Andreas 'ads' Scherbaum <[EMAIL PROTECTED]> wrote:
> But that's not the point: more people will run into this problem and
> this looks like a showstopper for updating to 8.3.
>
> By the way, the function is named quote_literal(), not quote_text().
> From my point of view i
On Nov 9, 2007 3:17 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> We want patch submitters to spend their time on patches, not learning
> our style. The fact is that pgindent is a silver bullet in some ways.
Well there's a lot of support for the idea of pgindent being good
enough to establish a
On Nov 8, 2007 2:49 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> None of these points in here seem at all analogous to the important kind of
> style details like what Tom was pointing out about using GETARG_* at the top
> of your function to make the argument types clear.
>
I would love to see
On 11/8/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> The problem is that a full list would be harder to understand than just
> looking at the existing code and following it, or taking suggestions
> from us as we review the patch.
>
What makes you say it would be necessarily harder to understand?
On 11/6/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> I understand your suggestions but it seems there would be too many
> individual items to be readable. Can you suggest a full list so we can
> get an idea of how long it would be?
If the body of material on writing good Postgres code becomes
On 11/1/07, Chris Browne <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Tom Lane) writes:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >> Perhaps both these considerations dictate providing another command or a
> >> special flavor of \l instead of just modifying it?
> >
> > I've seen no argume
On 11/1/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> I have not forgotten this suggestion. Do have any ideas what such a
> list would look like? Examples?
>
Thanks for the reply Bruce.
Code examples, perhaps with "good style" and "bad style" versions to
illustrate each point.
In the case o
On 10/24/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Brendan Jurd escribió:
> > Really? I just started playing around with git, and the output from
> > git diff produced the same kind of diff file I would normally get from
> > `svn di`
>
> ... which is a
> As we seem discussing developement in general, there is one
> obstacle in the way of individual use of DSCMs - context diff
> format as only one accepted. Both leading DSCMs - GIT and Mercurial
> do not support it.
>
Really? I just started playing around with git, and the output from
git diff
On 10/24/07, Greg Smith <[EMAIL PROTECTED]> wrote:
> 1) Make a converted copy of the existing CVS repository
> 2) Keep the mirrored repo up to date with new commits
> 3) Provide working guidelines so that developers can use the new VCS to
> build local patches and improve their productivity
> 4) Ge
On 10/24/07, David Fetter <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23, 2007 at 09:39:39AM +0100, Gregory Stark wrote:
> >
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >
> > > I'd rather encourage people to work in an incremental,
> > > not-so-big-bang fashion. Obviously one of the requirements for
On 10/17/07, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> New syntax:
>
> a) EXECUTE stringexpr
> [INTO [STRICT] varlist
> [USING exprlist]
>
> b) FOR varlist IN EXECUTE stringexpr USING exprlist LOOP
Just chiming in with a +1. I would find this feature very useful.
Substitution of
On 10/16/07, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> please, read:
> http://www.pgsql.cz/index.php/Automatic_execution_plan_caching_in_PL/pgSQL
>
Thanks Pavel,
I actually came across that wiki article via Google when I was first
trying to learn more about the message. But, I'm not asking for
On 10/16/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > I recently ran afoul of the following error message:
> > ERROR: type of "varname" does not match that when preparing the plan
> > IMO the message i
Hi hackers,
I recently ran afoul of the following error message:
ERROR: type of "varname" does not match that when preparing the plan
IMO the message isn't quite in English and doesn't explain the problem
very well. I'd like to change it to something more like
ERROR: the type of "varname" does
On 10/16/07, Neil Conway <[EMAIL PROTECTED]> wrote:
> See prior discussion:
>
> http://archives.postgresql.org/pgsql-bugs/2004-10/msg1.php
Thanks for the link. I did search the archives but unfortunately
terms like 'found' and 'execute' generate a lot of unwanted matches =)
>
> It would
Hi hackers,
Is there a technical reason we do not set the value of FOUND when
executing a dynamic statement in plpgsql?
It seems surprising that FOUND is set by SELECT, PERFORM, UPDATE,
INSERT, DELETE, etc, *except* when those statements are invoked by
EXECUTE.
I had a brief look at the code in
On 10/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Well, it's clearly useful in INSERT and UPDATE. For WHERE cases, you
> might or might not be able to use it, but I note that quote_nullable()
> would work much more like what happens if you use a parameter symbol
> and then bind NULL as the actual
On 10/10/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-10-10 at 14:57 +1000, Brendan Jurd wrote:
>
> > Wouldn't it be more useful if quote_literal(NULL) yielded the text value
> > 'NULL'?
>
> I don't think you can change that now. T
Hi hackers,
I note that if you pass NULL to quote_literal(), you get NULL.
This isn't surprising, but I was thinking that the stated purpose of
quote_literal is preparing the argument for entry into a dynamic SQL
statement. In this context, it fails for NULL input.
Wouldn't it be more useful if
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
Now that we've renamed the server binary to "postgres", what is the
status on use of the name "postmaster"? Is it now deprecated? And if
not, is there any point in keeping it around?
I've come across the occasional reference to "postmaster" in the FAQs
and I was thinking that this would confuse
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
On 10/1/07, Islam Hegazy <[EMAIL PROTECTED]> wrote:
> I am a graduate student in the University of Calgary. I want to add some new
> operators to PostgreSQL to perform some specific tasks in a project I am
> working in. My problem is that I cannot find my way into the code, where
> should I start a
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
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/22/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> On grounds of code-space savings I think it might be worth making
> these things be simple functions declared in builtins.h; that would
> also make it much easier to change their implementations.
I've noticed that this pattern isn't exclusive to th
Hi hackers,
In the process of trying to unify the various text/cstring conversions
in the backend, I came across some stuff that seemed weird in
pg_convert().
>From src/backend/utils/mb/mbutils.c:345:
Datum
pg_convert(PG_FUNCTION_ARGS)
{
bytea *string = PG_GETARG_TEXT_P(0);
Is this
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, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > I just noticed a couple of macros defined in src/include/tsearch/ts_utils.h:
>
> > #define TextPGetCString(t)
> > DatumGetCString(DirectFunctionC
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
d/access/common/heaptuple.c
src/backend/storage/large_object/inv_api.c
src/backend/executor/execQual.c
src/backend/catalog/pg_conversion.c
On 9/22/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>
> > On 9/22/07, Gregory Sta
On 9/22/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> The canonical way to do it is with
>
> DatumGetCString(DirectFunctionCall1(textout, t))
I just noticed a couple of macros defined in src/include/tsearch/ts_utils.h:
#define TextPGetCString(t)
DatumGetCString(DirectFunctionCall1(textout, Point
On 9/22/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
> The canonical way to do it is with
>
> DatumGetCString(DirectFunctionCall1(textout, t))
Ah, I see. Thanks.
In that case, would it be helpful if I submitted a patch for the
various code fragments that do this locally, updating them to use
Dat
Hi hackers,
I've noticed that there is a lot of code, particularly in src/backend,
that goes through the motions of making a text datum into a cstring to
perform some work on it, and likewise for making a cstring into a text
datum.
Is there not a nice macro somewhere to handle this consistently?
On 9/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> It would break functions that actually want to use a caller-specified
> search path, and protect themselves by explicitly schema-qualifying
> every other reference than one to some caller-specified object. Which
> admittedly is notationally a pain
Hi hackers,
I note that we currently expose the usefulness of the quote_identifier
function to the user with quote_ident(text).
Is there any reason we shouldn't do the same with quote_qualified_identifier?
We could just add a quote_qualified_ident(text, text) ... it would
make forming dynamic qu
On 9/5/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Am I on the right page?
>
> Got it in one, I believe.
In that case, +1 for your proposed changes.
At first, like Florian, I found the idea of a SET LOCAL ever
per
On 9/5/07, Michael Paesold <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > Basically my perspective on SET LOCAL is that its current behavior is a
> > bug, and even though it's been that way for a couple major releases now,
> > it's still something we oughta fix while we are busy whacking that par
On 9/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> I thought about ways to include GUC settings directly into CREATE
> FUNCTION, but it seemed pretty ugly and inconsistent with the
> existing syntax. So I'm thinking of supporting only the above
> syntaxes, meaning it'll take at least two commands to
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/18/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> The main drawback to the V1-call-convention function call mechanism,
> compared to ordinary C functions, is that you can't instantly see what
> the function arguments are supposed to be. I think that good coding
> style demands ameliorating this by
On 8/15/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > The consistent prefix idea sounds good; does "logging_enable" jive
> > with your proposal?
>
> I dislike it. I claim that logging to plain stde
On 8/15/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> For example, "log_line_prefix" is misnamed under this rule, and ought to
> be "logging_line_prefix". Similarly, redirect_stderr would become
> "logging_something" --- I'd prefer "logging_start_collector" but could
> live with "logging_collector" (o
On 8/9/07, Jaime Casanova <[EMAIL PROTECTED]> wrote:
>
> take your time, this seems like it will be for 8.4 anyway
>
I hear you, unfortunately "taking my time" usually means I forget
about it for eight months and by the time I come back to it I've
forgotten what I was doing =)
I wasn't really exp
Just quick update on this. It turns out (as it always does) that I
want to refactor a bit more intensively than I first suggested.
The functions dch_global, dch_time and dch_date seem to be wholly
pointless, since dch_global is effectively a one-liner for the FX
flag, and the other two merely wra
On 8/9/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > To my mind, it would make a lot more sense (and make hacking the file
> > a lot easier) if the processing functions were split into to_char and
> > fro
Hi hackers,
I'm currently poking around in backend/utils/adt/formatting.c with a
view to improving to_date() parsing (see thread at
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00513.php),
and I've noticed that the way the functions are organised is pretty
weird.
The original author a
On 7/18/07, Tom Lane <[EMAIL PROTECTED]> wrote:
This is all good but I think that self-inconsistent format strings are
not really the main source of to_date problems. Most of the complaints
I've seen arise from to_date plowing ahead to deliver a ridiculous
answer when the input data string doesn
On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Because this patch was not completed, I have added it to the TODO list:
* Fix to_date()-related functions to consistently issue errors
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00915.php
I'm now taking another run at this is
On 2/17/07, Martijn van Oosterhout wrote:
On Sat, Feb 17, 2007 at 02:41:32PM +1100, Brendan Jurd wrote:
> My gut reaction at first was to go with the former approach. It's
> programmatically more simple, and it's easier to explain in
> documentation/error messages. But the
On 2/17/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Bruce Momjian escribió:
> Maybe now would be an appropriate time to discuss the open questions in
> the submitting email:
> > Brendan Jurd wrote:
> > > I'd also like to raise the topic of how conversion f
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
Hey hackers,
I was doing some work in backend/utils/adt/formatting.c, and found the
following:
case DCH_D:
INVALID_FOR_INTERVAL;
if (is_to_char)
{
sprintf(inout, "%d", tm->tm_w
On 11/7/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Is it crucial that result sets be cleared before going out of scope?
It sounds like it'd leak memory inside psql; but realistically that's
probably not an enormou
While I was poking around in src/bin/psql/describe.c, I noticed that
when the query for inherited tables is opened, the code checks whether
the result is valid and if not, it goes straight to the error_return,
without clearing result sets that may have been open at the time. See
line 1174 in revi
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
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
Hello hackers,
I noticed that the table description given by \d in psql
does not indicate whether a trigger is enabled or disabled.
In my opinion, if a trigger is disabled, that fact is essential
information that a person looking at the output of \d would want to
know. I would like to add this
On 5/24/06, Josh Berkus wrote:
Brendan,
> There are two classes of intervals. One class, called year-month
> intervals, has an express or implied datetime precision that includes
> no fields other than YEAR and MONTH, though not both are required. The
> other class, called day-time intervals, h
Hi all,
I've been looking at the postgres interval implementation lately, and
I'm interested in putting together an improved implementation that
accords more closely with the SQL specification, in particular with:
---
4.6.2 Intervals
There are two classes of intervals. One class, called year-mo
On 8/14/05, Bruce Momjian wrote:
> Brendan Jurd wrote:
> > > We already have a TODO for this:
> > >
> > > * Add transaction_timestamp(), statement_timestamp(),
> > > clock_timestamp()
> > > functionality
> >
> > I lik
Hi Hackers,
I wasn't paying attention to the mailing lists (or the release notes)
when dollar-quoting was developed, and I stumbled across it in the
documentation today.
I just wanted to say, nice work!
I've definitely known the pain of doubling my single quotes ad
nauseum, and this is a fantast
> We already have a TODO for this:
>
> * Add transaction_timestamp(), statement_timestamp(),
> clock_timestamp()
> functionality
I like the idea of having a function for statement start time. I
think I'll incorporate it into my patch.
The suggested naming convention in the TO
401 - 500 of 513 matches
Mail list logo
