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 so
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 looking at the
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 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
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 no
limit.
5 connections seems a bit odd
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 bottom of \z?
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
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
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 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, 'second
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 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?
I think
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
happened, no
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 documentation
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 something on hold for
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
worlds.
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
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
year is just 12 months
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 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 connect
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 instructions on
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
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 type.
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
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
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)
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
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.
Thanks Tom
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
typename down into the child node from makeTypeCast
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 all.
Uh,
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 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 ArrayExpr is
a run-time representation and shouldn't have any
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 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 slope one: once we accept
this, what else? The entire point
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 subquery.
This has come up before
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 a
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 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 so
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 of Tom's
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 argument made why \l
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, 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 unified diff.
or `cvs di -c`.
Huh, strange
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
that will be
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) Get
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
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/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 be
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, 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 isn't quite in English and doesn't explain the problem
very well
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 help
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. There could be code out there
that relies on that behaviour
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
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 newer
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? And if
not, is there any point in keeping it around?
We should replace
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 *
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
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 and
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 the
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
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 currently expose the usefulness of the quote_identifier
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(DirectFunctionCall1(textout, PointerGetDatum(t)))
#define CStringGetTextP(c
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
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/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
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,
/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 Stark [EMAIL PROTECTED] wrote:
The canonical way to do
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
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 in
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 part
of
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
persisting beyond a function astonishing, but that's
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 thought
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
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:
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 (or maybe
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 stderr (without the
syslogger process) is still logging. Logging to syslog
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 expecting
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
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
from_char variants. I'm not sure what, if any, advantage
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
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
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
On 2/17/07, Martijn van Oosterhout kleptog@svana.org 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
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 from text to ISO
week dates should
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,
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:
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 triggers
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
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 enormous problem for this usage. How much
Hello hackers,
I noticed that the table description given by \d tablename 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
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
On 5/24/06, Josh Berkus josh@agliodbs.com 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
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 TODO
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
On 8/14/05, Bruce Momjian pgman@candle.pha.pa.us wrote:
Brendan Jurd wrote:
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 apologize that my server was down Monday/Tuesday, rendering the
patches queue unavailable. I also apologize that my secondary MX was
misconfigured, causing some email bounces. I think everything is fixed
now.
Hi Bruce,
I was checking out the patches queue, and there seems to be a
Hi all,
I propose to add an internal function gettime() that transparently
returns the current system time, as a timestamptz with maximum
precision.
Calling gettime() would be a more elegant approach than calling
timeofday() and converting it to a timestamp, and avoids some of the
potential
401 - 500 of 511 matches
Mail list logo
