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
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
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
Originally posted in psql-general, submitted here as a prospective RFE:
When using a row-returning function (RETURNS SETOF record) in the FROM
clause of a query, you have to supply a column definition list. I was
recently attempting to use a row-returning function in a query and
received the
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
ERROR: query-specified return row and actual function return row do not
match
With that in mind, I'd like to submit a request, that the verbosity of
this error message be increased to explain which ordinal column position
I've got an idea for a new internal function. I'm more than willing to
code it myself, but I'd like to run it past the list and thrash out any
conceptual issues before I get too excited about writing a patch.
When dealing with time values, it's not unknown to want to see a
particular time
Kris Jurka wrote:
On Sat, 15 Jan 2005, Brendan Jurd wrote:
SELECT time_span( 'minute', now(), interval '10:43:55' );
643
The timestamp argument to this version of the function seems completely
irrelevent.
Kris Jurka
I don't think so. As I pointed out in the OP, to make this function
Tom Lane wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
Of course, it would be possible to create a shorthand version of the
function which expects (text, interval), and passes directly to
time_span($1, now(), $2).
This bothers me a bit. That essentially says that (text, interval)
has
Neil Conway wrote:
I would be OK with just ignoring this case, but on reflection I would
prefer removing the -t schema.table syntax. Removing the feature
resolves the quoting issue and also simplifies pg_dump's behavior. We
lose the ability to dump table t1 in schema s1 and table t2 in schema s2
As someone who's been lurking on the postgres lists for quite some
time, and submitted one (minor) patch, I think the notion of an
entry-level task list for we beginners is fantastic.
And, I'm sure this has been asked and answered a billion times
already, but why *don't* we have a real bug
On 5/18/05, Marc G. Fournier [EMAIL PROTECTED] wrote:
The key requirement that has always come up is that the core developers
wouldn't use anything web based, so the tracker would have to somehow tie
into the mailing lists themselves ...
What's the basis of this objection to a web-based
On 5/18/05, Tom Lane [EMAIL PROTECTED] wrote:
The Postgres project has been exceedingly successful while using email
lists as the primary means of communication/organization. I for one
am disinclined to tinker with such a fundamental aspect of the way that
the community operates. If we try
On 5/18/05, Stephen Frost [EMAIL PROTECTED] wrote:
* Brendan Jurd ([EMAIL PROTECTED]) wrote:
In the interests of putting my money where my mouth is, I would be
willing to enlist in the housekeeping effort for this hypothetical new
system.
If you're willing to create it, host it, update
On 5/18/05, Joshua D. Drake [EMAIL PROTECTED] wrote:
O.k. then I misunderstood and apologize. I think the above is
reasonable. I wouldn't think that the main developers would stop
developing to create this system, nor would I want them to take time
away from development to implement it.
I
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
On Sun, Aug 31, 2008 at 6:18 AM, Tom Lane [EMAIL PROTECTED] wrote:
I'm fooling around with getting the parser to report an error cursor
location if input conversion fails for a constant in a SQL command.
...
This seems like it'd be a pretty useful thing to have in long queries,
but in short
On Tue, Sep 2, 2008 at 2:03 PM, David E. Wheeler [EMAIL PROTECTED] wrote:
BTW, anyone have any interest in this function in core? Its purpose is to
return a string identifying the data type of its argument. It's useful for
dynamically building queries to pass to PL/pgSQL's EXECUTE statement
On Tue, Sep 2, 2008 at 2:57 PM, Tom Lane [EMAIL PROTECTED] wrote:
Neil Conway [EMAIL PROTECTED] writes:
Returning regtype seems like the natural choice.
I was just about to say the same.
Yes. In fact, the way I typically use the function is to write
gettype(whatever)::regtype. I was too
On Wed, Sep 3, 2008 at 3:39 AM, Tom Lane [EMAIL PROTECTED] wrote:
The description of the CommitFestBlank template suggests that it sets up
an editable page for you, but AFAICT it does no such thing. I had to
manually create all the right sections:
On Wed, Sep 3, 2008 at 10:31 AM, Tom Lane [EMAIL PROTECTED] wrote:
It still seems a bit awkward though. AFAICS the sentence about
This is the page for CommitFest starting 2008 November would
have to be inserted after committing the first version of the
page?
Yes, you do have to perform
On Wed, Sep 3, 2008 at 10:55 AM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I suppose we could introduce an argument to the template, so that you
would call it with {{subst:CommitFestBlank|November 2008}}, but it's
only going to save us one edit. I can add
On Tue, Sep 2, 2008 at 3:31 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
Barring any further comments/objections, I'll go ahead and prepare a
patch to add this to core.
Any opinions on where pg_typeof() should be defined? This function is
a little unusual and doesn't seem to slot nicely into any
On Fri, Sep 5, 2008 at 6:54 AM, Simon Riggs [EMAIL PROTECTED] wrote:
On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
Please volunteer now!
Everybody is stuck in I'm not good enough to do a full review. They're
right (myself included), so that just means we're organising it wrongly.
We
On Tue, Aug 19, 2008 at 12:24 PM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Ok, I rewrote the patch to use SIGALRM instead of gettimeofday.
Hi Itagaki-san,
Josh assigned your patch to me for an initial review. Here's what I
have so far.
The patch applies cleanly on the latest git HEAD, and
Hello again,
I received the following email from a helpful fellow off-list,
pointing out an error in my review:
On Fri, Sep 5, 2008 at 7:03 PM, Ragnar [EMAIL PROTECTED] wrote:
On fös, 2008-09-05 at 15:07 +1000, Brendan Jurd wrote:
Wouldn't this be better written
On Sat, Sep 6, 2008 at 10:10 AM, Tom Lane [EMAIL PROTECTED] wrote:
* the way you had it set up, the CREATE OR REPLACE FUNCTION command
would be sent to the backend instantaneously upon return from the
editor, with no opportunity for the user to decide he didn't want his
changes applied. This
On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
Im just following this:
http://wiki.postgresql.org/wiki/Reviewing_a_Patch so lets get started.
Hi Alex. Thanks for taking the time to review my patch.
Feature test: Everything seems to work as advertised. However before
On Mon, Sep 8, 2008 at 6:24 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Sun, Sep 7, 2008 at 5:58 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
Code review: one minor nit
*** a/src/backend/utils/adt/formatting.c
--- b/src/backend/utils/adt/formatting.c
***
*** 781,787 static
On Mon, Sep 8, 2008 at 6:59 PM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Here is a revised version of the pgbench duration patch.
I merged some comments from Brendan and gnari.
The changes look good. I tried out the new v3 patch and didn't
encounter any problems.
One last minor quibble - I
On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
I actually had a look at this patch also, though not as thoroughly as
Alex. There was one part that I had some thoughts about in
from_char_parse_int_len:
Hi Martijn. Thanks for your comments.
The use of
On Tue, Sep 9, 2008 at 9:04 PM, Brendan Jurd [EMAIL PROTECTED] wrote:
On Tue, Sep 9, 2008 at 7:29 PM, Martijn van Oosterhout
[EMAIL PROTECTED] wrote:
The use of palloc/pfree in this routine seems excessive. Does len have
upper bound? If so a simple array will do it.
I suppose I could define
On Fri, Sep 12, 2008 at 3:34 AM, Tom Lane [EMAIL PROTECTED] wrote:
Applied with minimal modifications. I changed a couple of error
messages that didn't seem to meet the style guidelines,
Great, thanks Tom. And thanks again to Alex and Martijn for helping
me refine the patch.
and I moved all
Hi Magnus,
Josh has assigned your patch to me for an initial review.
First up I'd like to say that this is a really nice upgrade.
Shielding a running server from reloading a bogus conf file makes a
whole lot of sense.
On Sun, Aug 17, 2008 at 1:47 AM, Magnus Hagander [EMAIL PROTECTED] wrote:
On Mon, Sep 15, 2008 at 10:53 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Thanks for the reviews, guys. I've adjusted the patch per your comments
(I think), and applied it.
Cool. I had a look at the commitdiff and I think you missed one of
the error messages (it's still all on one line).
On Mon, Sep 15, 2008 at 11:46 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Hm, that doesn't seem like a great improvement --- in particular, it
violates the style guideline that detail messages should be complete
sentences.
I think the error text is all right as-is, really.
Hey folks,
Tom pointed out in the parent thread [1] that the error message for
bogus AM/PM markers in to_timestamp is pretty lame:
ERROR: invalid AM/PM string
I agree, and once I started thinking about this, I came up with other
gripes concerning the treatment of 12-hour time in
On Sat, Sep 27, 2008 at 4:08 AM, Tom Lane [EMAIL PROTECTED] wrote:
Alex Hunsaker [EMAIL PROTECTED] writes:
However that still leaves the original complaint around (at least IMHO):
select to_timestamp('AN', 'AM');
ERROR: invalid AM/PM string
select to_timestamp('11:47 PM 27 Sep a2008',
On Mon, Nov 3, 2008 at 2:31 PM, Tom Lane [EMAIL PROTECTED] wrote:
The problem I'm having with this is that the current scheme for naming
commitfest pages assumes you know the date for each one. It seems way
premature to bet on when the first 8.5 fest will start.
Wikimedia does seem to
Hi Jeff,
I've been assigned to do an initial review of your new correlation
metric patch.
If I'm grokking the thread, it looks like Tom suggested a substantial
change in the approach (targetting per-index correlation rather than
per-column) [1], and although you agreed with the spirit of his
On Tue, Nov 4, 2008 at 6:12 AM, Enrico Pirozzi [EMAIL PROTECTED] wrote:
Hi all, I'm new in list
Hi Enrico,
Just a heads-up, the Postgres hackers have just started on the final
commitfest (patch review phase) for the 8.4 development cycle, so at
the moment everyone is busy reviewing patches
On Tue, Nov 4, 2008 at 4:21 AM, Jeff Davis [EMAIL PROTECTED] wrote:
We don't want to hold anything up, so feel free to move on to another
patch. If you still have time to review when we have a better patch,
we'd appreciate your feedback even if it's too late for 8.4.
No worries, thanks Jeff.
On Thu, Sep 18, 2008 at 6:03 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
The attached patch
(1) adds a new GUC called IntervalStyle that decouples interval
output from the DateStyle GUC, and
(2) adds a new interval style that will match the SQL standards
for interval
On Wed, Nov 5, 2008 at 7:34 AM, Ron Mayer [EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
When I ran the regression tests, I got one failure in the new interval
Fixed, and I did a bit more testing both with and without
HAVE_INT64_TIMESTAMP.
Confirmed, all regression tests now pass on my system
On Thu, Oct 2, 2008 at 9:31 PM, Ron Mayer [EMAIL PROTECTED] wrote:
Ron Mayer wrote:
This patch (that works on top of the IntervalStyle patch I
posted earlier today) adds support for ISO8601 standard[0]
Time Interval Durations of the format with designators
(section 4.4.4.2.1). The other ISO
On Thu, Nov 6, 2008 at 3:36 AM, Ron Mayer [EMAIL PROTECTED] wrote:
Wow thanks! That's very helpful (though it might have been more
fair to your time if you just kicked it back to me saying rewrite
the docs so they make sense)!
Maybe ... but I figured it would take more time to fully explain
On Fri, Nov 7, 2008 at 3:35 AM, Ron Mayer [EMAIL PROTECTED] wrote:
I think I updated the web site and git now, and
'P-00-01' is now accepted. It might be useful if
someone double checked my reading of the spec, tho.
Hi Ron,
I've tested out your latest revision and read the spec more
On Tue, Nov 11, 2008 at 2:36 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
I updated my web site[1] with the latest version of this patch.
I'm just testing this latest version out now.
I get the expected result from 'P0001', but oddly enough if I specify
only the year and month, it pukes:
postgres=#
On Sat, Nov 8, 2008 at 2:19 AM, Ron Mayer [EMAIL PROTECTED] wrote:
Hmmm... Certainly what I had in datatype.sgml was wrong, but I'm
now thinking 5.5.4.2.1 and 5.5.4.2.2 would be the most clear?
Sorry, I don't understand what you mean by 5.5.4.2.1. In the spec
you linked to, clause 5 Date and
On Tue, Nov 11, 2008 at 5:51 AM, R Mayer
[EMAIL PROTECTED] wrote:
Applied and pushed to the website http://0ape.com/postgres_interval_patches/
This latest version works as expected and I don't detect any other
issues with the code or documentation ... seems I've run out of things
to gripe
On Sat, Nov 1, 2008 at 3:42 PM, Ron Mayer [EMAIL PROTECTED] wrote:
# Patch 3: cleanup.patch
Fix rounding inconsistencies and refactor interval input/output code
Compile, testing and regression tests all checked out.
I've picked up on a few code style issues, fixes attached.
If I'm reading
On Wed, Nov 12, 2008 at 5:32 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
* AdjustFractionalSeconds = AdjustFractSeconds
* AdjustFractionalDays = AdjustFractDays
Otherwise many lines were over 80 chars long.
And it happened often enough I thought the shorter name
was less
On Wed, Nov 12, 2008 at 6:13 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
Brendan Jurd wrote:
I don't have any further gripes regarding this patch, apart from the
code style stuff I sent through in my previous post. Did you have any
response to those?
Yup - you were right again.
Applied them
On Thu, Nov 13, 2008 at 4:52 AM, Tom Lane [EMAIL PROTECTED] wrote:
Yeah. An example of a closely related expression that it *would* be
able to prove self-contradictory is
WHERE x = ALL (ARRAY[1, 2, ...])
or perhaps slightly more realistically
WHERE x = ANY (ARRAY[1, 2, 3]) AND
On Thu, Nov 13, 2008 at 5:16 AM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I guess my question is, what's the real benefit of going to all this
trouble trying to prove that clauses are false?
Not having to scan gigabytes of data in an excluded partition
On Tue, Nov 25, 2008 at 7:31 PM, Dave Page [EMAIL PROTECTED] wrote:
I'm in favour of including it by default (at initdb), so it's there
for new users to play with on any fresh install ...
Could we perhaps punt on the issue of whether to install the
sampledb by default. It could be controlled
On Mon, Dec 1, 2008 at 11:08 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
postgres=# SELECT to_timestamp('29-12-2005 01:02:3', 'DD-MM-
HH24:MI:SS'); -- doesn't work
...
I think the end of string should be treated like a field separator, colon in
this example, and we should accept both
2009/11/10 Joshua Tolley eggyk...@gmail.com:
Ok, updated patch attached. As far as I know, this completes all outstanding
issues:
Hi Joshua,
I'm taking a look at this patch for the commitfest. I see that Andrew
has already taken an interest in the technical aspects of the patch,
so I'll
2009/11/16 Andrew Dunstan and...@dunslane.net:
At Tom's suggestion I am looking at allowing use of parameter names in SQL
functions instead of requiring use of $1 etc. That raises the question of
how we would disambiguate a parameter name from a column name. Essentially,
ISTM, we could use
2009/11/16 Tom Lane t...@sss.pgh.pa.us:
The real problem with the entry that George picked up on was that it was
misdescribed and mislabeled as easy because whoever put it in ignored
the fact that there was not a consensus to do a half-baked fix ...
this is a problem with a wiki TODO list :-(
2009/11/17 David Fetter da...@fetter.org:
In the PostgreSQL Weekly News, I track patches, and apparently at
least one person reads that section. Would it be helpful to track
reviews somehow during commitfests with the reviewers' names
prominently attached?
Yes. See also my suggestion [1]
2009/11/17 Joshua Tolley eggyk...@gmail.com:
On Sun, Nov 15, 2009 at 12:10:33PM +1100, Brendan Jurd wrote:
I noticed that there was a fairly large amount of bogus/inconsistent
whitespace
...
Thanks -- I tend to forget whitespace :)
In the documentation you refer to this feature as inline
2009/11/29 Bruce Momjian br...@momjian.us:
Wow, we mention 28k modems --- we are legacy software: ;-)
This initial checkout is a little slower than simply downloading
a filenametar.gz/filename file; expect it to take 40 minutes
or so if you have a 28.8K modem.
Yes, and what
2009/12/3 Ron Mayer rm...@cheapcomplexdevices.com:
Tom Lane wrote:
Hmm. So the argument for it is let's make a machine-readable format
more human-readable? I'm not getting the point. People should look
at the regular text output.
IMHO YAML beats the regular text format for
2009/12/20 Peter Eisentraut pete...@gmx.net:
Could we create an option to create index names automatically, so you'd
only have to write
CREATE INDEX ON foo (a);
Yes, please.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
2010/1/23 Mark Mielke m...@mark.mielke.cc:
Calling it
PostgreSQL, makes it very clear to the uninformed masses where the product
fits in a product map. Tell an executive of a company Postgres, and they
would ask what is it? Tell them PostgreSQL, and they'll say is that
like Oracle? The second
On 3 March 2010 14:34, Bruce Momjian br...@momjian.us wrote:
Scott Bailey wrote:
Tom Lane wrote:
Asher Hoskins as...@piceur.co.uk writes:
I can't seem to get to_timestamp() or to_date() to work with quarters,
The source code says
* We ignore Q when converting to date
On 4 March 2010 04:08, Tom Lane t...@sss.pgh.pa.us wrote:
Brendan Jurd dire...@gmail.com writes:
For example, you're trying to import a date that is written as Wed
3rd March, Q1 2010. You might give to_date a format string like 'Dy
FMDDTH Month, QQ ' and expect to get the correct answer
On 8 April 2010 06:46, Tom Lane t...@sss.pgh.pa.us wrote:
Not a lot of zero suppression happening there :-(.
I believe the correct fix is to reduce the year mod 100 (or 10 or 1000)
before feeding it to snprintf, rather than playing games with printing
only part of the result string as the
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
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 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
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/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
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 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
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
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
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,
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/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
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
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
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 *
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
1 - 100 of 511 matches
Mail list logo
