On Sat, 2007-04-21 at 17:56 -0400, Neil Conway wrote:
Right, I'm envisioning doing a conditional LockAcquire and then
heap_open() / heap_getnext() by hand. That will be relatively slow, but
code that emits a deadlock error message is almost by definition not
performance critical.
... although
The error message we currently produce when a deadlock occurs is pretty
unfriendly:
ERROR: deadlock detected
DETAIL: Process 32068 waits for AccessExclusiveLock on relation
16413 of database 16384; blocked by process 32064.
Process 32064 waits for AccessExclusiveLock on relation
On Fri, 2007-04-20 at 02:55 -0400, Tom Lane wrote:
I don't think you've thought of quite all of the failure cases. One
that's a bit pressing is that a deadlock isn't necessarily confined to
objects in your own database.
I'm not sure I follow. If we conditionally acquire the locks we need and
On Mon, 2007-04-16 at 03:48 +0200, Florian G. Pflug wrote:
I just realized that this file isn't even in the postgresql CVS
repo. But it _is_ part of the SVN mirror at
https://projects.commandprompt.com/public/pgsql/repo.
[...]
Seems to be a bug in the CVS-SVN conversion process...
The root
On Thu, 2007-04-12 at 11:45 -0400, Alvaro Herrera wrote:
This phrase is missing a verb:
[...]
I find this markup strange:
[...]
In ResetTempTableNamespace(void), shouldn't it be using myTempNamespace
instead of the SysCache lookup?
All fair points: I've applied the attached patch. Thanks
On Tue, 2007-04-10 at 18:28 +0200, Peter Eisentraut wrote:
The problem is that most of the standard methods are platform dependent, as
they require MAC addresses or a good random source, for instance.
http://archives.postgresql.org/pgsql-patches/2007-01/msg00392.php
ISTM random() or similar
In CVS HEAD:
contrib/tsearch2/dict_syn.c:124: warning: 'slen' is used uninitialized
in this function
Induced by the recent pg_verifymbstr() patch.
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Bruce Momjian wrote:
FYI, I have received permission, below, to remove the Andrew Yu
copyright. Thanks.
Can't we just remove the file outright? The last release of Ultrix was
in 1995.
-Neil
---(end of broadcast)---
TIP 3: Have you
Bruce Momjian wrote:
Someone has pointed out that the following files have the 4-part BSD
copyright, which includes the advertising clause:
src/backend/port/darwin/system.c
src/backend/port/dynloader/freebsd.c
src/backend/port/dynloader/openbsd.c
D'Arcy J.M. Cain wrote:
On Tue, 20 Mar 2007 11:24:00 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
# -Make 64-bit version of the MONEY data type
Actually, this TODO is DONE. It's in HEAD now.
That is what the - prefix denotes.
-Neil
---(end of
Andrew Dunstan wrote:
I'm not convinced it would be a huge gain anyway. Switching madly in
and out of the perl interpreter at least is a known performance
problem, IIRC
Returning control to the backend for every row returned would likely be
excessive, but you could return once every k rows
On Thu, 2007-03-08 at 17:35 +, Gregory Stark wrote:
When I was running tests I did it on a filesystem where nothing else was
running. Between tests I unmounted and remounted it. As I understand it Linux
associates the cache with the filesystem and not the block device and discards
all
On Tue, 2007-03-06 at 00:18 -0500, Tom Lane wrote:
Sounds like #ifdef time to me --- but it seems a bit strange; wouldn't
the Python guys have taken a bit more care for compatibility of
user-supplied code?
Yeah, I was a bit surprised as well. I won't claim to have any
familiarity with the
On Sat, 2007-03-03 at 14:29 -0500, Neil Conway wrote:
No, it just looks like a Python API 2.5 change to me
Attached is a patch that fixes the warnings. Unfortunately, it seems
this patch won't compile against Python 2.4: the 2.5 API requires the
use of some typedef's that AFAICS were only
FYI, I see the following warnings compiling CVS HEAD:
src/pl/plpython/plpython.c:2006: warning: initialization from
incompatible pointer type
src/pl/plpython/plpython.c:2008: warning: 'intargfunc' is deprecated
src/pl/plpython/plpython.c:2008: warning: initialization from
incompatible pointer
On Sat, 2007-03-03 at 11:21 -0800, Joshua D. Drake wrote:
There is no Ubuntu Fiesty... yet ;) you are compile -head with -head...
sounds like a snafu to begin with
No, it just looks like a Python API 2.5 change to me. I'd look into it
myself, but I don't have the free cycles at the moment.
On Tue, 2007-02-27 at 14:52 -0800, Joshua D. Drake wrote:
Gonna have to concur with that. Not that the sig is legally binding
anyway, we do need to have a disclaimer in the email stating that you
are assigning to PGDG
I think it's pretty silly to start caring about this now. Do you think
that
On Tue, 2007-02-27 at 16:20 -0800, Joshua D. Drake wrote:
Thus we may literally not have rights to the code. Do you really want to
go down the path of in 2 years, Fujitsu (No offense Fujitsu), but you
are the topic) decides that the code they provided is owned by them and
they didn't give us
On Fri, 2007-02-23 at 18:02 -0500, Tom Lane wrote:
Yah know, the one bit of these pitches that always sounds like pure
snake oil is the claim that they offer some kind of mechanical solution
to merge conflicts. AFAICS that has nothing to do with the SCMS in use
and everything to do with
On Thu, 2007-02-22 at 14:49 -0300, Alvaro Herrera wrote:
For example, currently if I have a patch and somebody reviews it and
opines that I have to change foo to bar; then I resubmit the patch. How
do they find out whether I actually changed foo to bar? Currently there
are two alternatives:
On Wed, 2007-02-14 at 13:19 -0300, Alvaro Herrera wrote:
Probably stack allocation doesn't matter much, as I think that would be
unwinded by the longjmp call. I don't know a lot about C++, but if
there are allocations in the data area then those would probably not be
freed. But it makes me
On Tue, 2007-02-06 at 12:33 -0600, Bruno Wolff III wrote:
Is a test going to get added to the regression tests to catch similar
regressions in the future?
While we can modify the regression tests to catch this specific problem
in the future, I wonder if there ought to be more testing of
On Sun, 2007-01-28 at 20:47 +0100, Magnus Hagander wrote:
uuid_t is defined to UUID in the win32 platform SDK header files. I
would suggest we use pguuid_t or something like that instead.
We could possibly try to workaround it by #undef'ing any existing uuid_t
definitions before we supply our
On Thu, 2007-01-25 at 18:16 -0500, Jan Wieck wrote:
For conflict resolution purposes in an asynchronous multimaster system,
the last update definition often comes into play. For this to work,
the system must provide a monotonically increasing timestamp taken at
the commit of a transaction.
On Wed, 2007-01-24 at 13:49 -0500, Tom Lane wrote:
2) once we put this in core we are going to be stuck with supporting its
SQL API forever. Are we convinced that this API is the one we want?
I don't recall even having seen any proposal or discussion.
There has been some prior discussion:
On Wed, 2007-01-24 at 18:38 -0300, Alvaro Herrera wrote:
In any case, I agree with Andrew that it would be pretty dumb to reject
a funded, already written patch.
Well, there are two separate issues: should we include tsearch2 in core,
and what syntax should it use? Changing the syntax would not
On Wed, 2007-01-24 at 08:26 -0800, Sorin Schwimmer wrote:
The front-end application can do it easy in a
loop of a sort, but on remote servers (and that's the
norm these days) it creates unnecessary network
traffic.
You can avoid this easily via a stored procedure.
My suggestion is to allow
$ make -C src/test/regress runtest
[ ... ]
test xml ... FAILED
test stats... ok
test tablespace ... ok
1 of 105 tests failed.
The regression.diffs are attached. Note that this reproduces
consistently,
On Wed, 2007-01-17 at 08:51 +0100, Stefan Kaltenbrunner wrote:
this seems to require an alternative regression output file on windows
Hmm, right. Easiest fix seems to be just removing the platform-dependent
output from the regression test, since it wasn't necessary -- committed
to CVS HEAD. (I
On Mon, 2007-01-15 at 10:51 -0800, Richard Troy wrote:
I therefore propose that the engine evaluate -
benchmark, if you will - all functions as they are ingested, or
vacuum-like at some later date (when valid data for testing may exist),
and assign a cost relative to what it already knows -
On Mon, 2007-01-15 at 15:05 -0500, Tom Lane wrote:
maybe we should just do the constant for starters and see how many
people really want to write C-code estimators ...
+1
BTW, your proposal would still pushdown all qualifiers, right?
Hellerstein's xfunc work discusses situations in which it
On Thu, 2007-01-11 at 14:36 -0500, Neil Conway wrote:
I don't think they need to be integrated any time soon, but if we were
to design pg_dump and pg_dumpall from scratch, it seems more logical to
use a single program
On thinking about this some more, it might be useful to factor much
On Fri, 2007-01-12 at 22:24 +, Simon Riggs wrote:
This item was rejected by Tom, since a workaround exists
Add estimated_count(*) to return an estimate of COUNT(*)
This would use the planner ANALYZE statistics to return an estimated
count.
On Thu, 2007-01-11 at 21:04 -0500, Neil Conway wrote:
Comments? I'll write up a doc patch, barring any objections.
I'll apply the attached doc patch to CVS tomorrow, barring any
objections.
-Neil
Index: doc/src/sgml/datatype.sgml
On Fri, 2007-01-05 at 17:52 -0500, Tom Lane wrote:
I think this will be an exercise in time-wasting, and very possibly
destabilize *both* tools. pg_dump has never been designed to reconnect
to a different database; for instance there isn't any code for resetting
all the internal state that it
postgres=# select 'NaN'::numeric = 'NaN'::numeric,
'NaN'::float8 = 'NaN'::float8;
?column? | ?column?
--+--
t| t
(1 row)
This behavior is inconsistent with most people's notion of NaN -- in
particular, it is inconsistent with IEEE754. I can understand
On Wed, 3 Jan 2007 10:16:41 -0500
Jim Nasby [EMAIL PROTECTED] wrote:
Given that the TODO list is the official compilation of things that
need to get done, ISTM that anything warranting a TODO or XXX in the
code should probably be on the TODO list.
There are a wide class of possible
Jeremy Drake said:
http://momjian.us/mhonarc/patches_hold/msg00162.html
There is no patch or anything associated with it, just the
suggestion that it be put in when 8.3 devel starts up.
Right -- this is on my TODO list for 8.3. I'm traveling at the
moment, but I can send a patch for this in a
On Tue, 2006-12-12 at 17:30 -0500, Bruce Momjian wrote:
* Have EXPLAIN ANALYZE highlight poor optimizer estimates
TODO updated:
* Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and
actual row counts differ by a specified percentage
I don't think this is
Tom Lane wrote:
Yeah ... a protocol change is *painful*, especially if you really want
clients to behave in a significantly new way.
A backward-incompatible protocol change is painful, sure, but ISTM we
could implement what Greg describes as a straightforward extension to
the V3 protocol.
Simon Riggs wrote:
I like the idea, but its more work than I really wanted to get into
right now.
Well, from another point of view: do we need this feature so urgently
that there is not enough time to do it properly? IMHO, no.
-Neil
---(end of
On Tue, 2006-11-07 at 16:21 +1100, Brendan Jurd wrote:
Minor fix to the previous patch; result7 was not being cleared at the
end of the block.
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.
On Tue, 2006-11-07 at 17:56 +1100, Brendan Jurd wrote:
It certainly isn't pretty. It's been a long time since I looked down
the barrel of a 'goto'.
I don't think there's anything wrong with using goto for error
handling in this style. Personally, I think the main stylistic problem
is that the
On Tue, 2006-11-07 at 17:56 +1100, Brendan Jurd wrote:
Should be just six extra lines (patch attached, untested).
Applied to HEAD, with an additional fix: you need to clear result5 as
well. I didn't bother applying it to backbranches, on the grounds that a
memory leak in psql is not serious.
I
On Sun, 2006-11-05 at 01:15 -0500, [EMAIL PROTECTED] wrote:
Compiled fine. Still a few warnings (using Fedora Core 6 / AMD64).
Presumably those are just the standard warnings we can't easiy
eliminate. If not, can you post them please?
-Neil
---(end of
On Sat, 2006-11-04 at 23:34 -0500, Tom Lane wrote:
Perhaps use a PG_TRY construct?
At least for the existing code, this doesn't work well: the function
exits early via ereport(LOG) and then return STATUS_ERROR;, so AFAICS
there isn't an easy way to simplify the existing error handling logic
via
On Sun, 2006-11-05 at 19:28 -0500, Tom Lane wrote:
Come to think of it: either elog(ERROR) or a failure return from
CheckLDAPAuth is going to lead directly to backend exit, so the
whole thing is pretty much a cosmetic issue anyway.
Thanks for the feedback. Patch applied, with an additional
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
Nothing except initdb should add objects in pg_catalog. AFAICS,
adminpack doesn't have any special requirements, so it should behave
like all other contrib modules.
Where are we on this? When this topic was last discussed, the three
On Thu, 2006-11-02 at 23:53 +0500, imad wrote:
Shouldn't we turn on warnings by the compiler on uninitialized
variables? This can also be helpful.
Those warnings should already be enabled, at least with GCC.
-Neil
---(end of broadcast)---
TIP
On Thu, 2006-11-02 at 14:23 -0500, [EMAIL PROTECTED] wrote:
Yes, the compiler can detect unitialized variables,
In most situations, anyway.
I've seen too many less-scarred developers add an = NULL to quiet
down the tool. But that's (arguably) worse than leaving the variable
uninitialized
On Fri, 2006-10-27 at 15:59 +0200, Peter Eisentraut wrote:
I appreciate this effort, but I think it's better to hold the patch.
Sure, I'll wait for 8.3 to branch.
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please
On Fri, 2006-10-27 at 03:50 -0500, Andrew Dunstan wrote:
psql variables and commands are not SQL, and are case sensitive. For
example, \ds and \dS are not at all the same.
This is documented clearly on the psql man page, so it is simply not a
bug
It may be documented, but \set still has a
On Fri, 2006-10-20 at 11:50 +0200, Andreas Pflug wrote:
Having pg_dump not saving the function definitions is an intended
behaviour.
The manual defines the pg_catalog schema as containing the system
tables and all the built-in data types, functions, and
operators (section 5.7.5). adminpack is
On Fri, 2006-10-20 at 05:52 +0100, Dave Page wrote:
The adminpack was originally written and intended to become builtin
functions
This is not unique to adminpack: several contrib modules might
eventually become (or have already become) builtins, but adminpack is
the only module that defines
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
Nothing except initdb should add objects in pg_catalog. AFAICS,
adminpack doesn't have any special requirements, so it should behave
like all other contrib modules.
Okay. Are there any opinions on whether we should make this change
On Fri, 2006-10-20 at 16:05 -0700, dakotali kasap wrote:
1. How can I prepare my own query plan?
You can't: there is currently no public API for constructing plans by
hand. You could kludge something up by hand, but it would be pretty
fragile (internal planner data structures may well change
On Thu, 2006-10-19 at 19:52 +0200, Magnus Hagander wrote:
I've set up my laptop to sync down the full cvs repository using rsync
(remember - windows = no cvsup).
Yeah, I do this as well, and for similar reasons (cvsup is unmaintained
and annoying to build, at least on AMD64/Debian).
This
On Thu, 2006-10-19 at 13:56 -0400, Tom Lane wrote:
Is it worth renaming our qsort to pg_qsort to avoid this? (I'd be
inclined to do that via a macro #define qsort pg_qsort, not by running
around and changing all the code.)
Why not change each call site? I don't think it would hurt to be clear
Why does adminpack install functions into pg_catalog? This is
inconsistent with the rest of the contrib/ packages, not to mention the
definition of pg_catalog itself (which ought to hold builtin object
definitions). And as AndrewSN pointed out on IRC, it also breaks
pg_dump.
-Neil
On Wed, 2006-10-18 at 15:44 +0200, Andreas Joseph Krogh wrote:
I'm not advocating that NULL should have a string-vaule of anything, just
that
the ||-operator shuld treat NULL as dont bother with it and proceed
concatenation.
Not only is the current behavior more logical (IMHO) and backward
On Mon, 2006-10-16 at 13:59 +0200, Markus Schaber wrote:
It's already possible to do this, just create the TABLESPACE in a
ramdisk / tmpfs or whatever is available for your OS.
This is not an ideal solution: if the machine reboots, the content of
the tablespace will disappear, requiring manual
On Sun, 2006-10-15 at 19:56 +0200, Martijn van Oosterhout wrote:
Sure, I even implemented it once. Didn't get any faster.
Did you just do something akin to s/read/aio_read/ etc., or something
more ambitious? I think that really taking advantage of the ability to
have multiple I/O requests
On Thu, 2006-10-12 at 21:11 +0200, Peter Eisentraut wrote:
Actually the patch was previously rejected.
Oh? Sorry, I must have missed that. On what grounds was it rejected?
-Neil
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Tue, 2006-10-10 at 20:17 -0500, Jim C. Nasby wrote:
IIRC there was an intention to allow ownership reassignment of all
objects in the database. Somehow views got missed
ALTER TABLE can change view ownership (as well as sequence ownership).
You could argue for the addition of an ALTER VIEW
On Tue, 2006-10-10 at 20:27 -0500, Jim C. Nasby wrote:
Wow, that's news to me. I'll prepare a docs patch to reflect that.
It is already reflected in the docs, although it might need to be more
prominent.
Is there any other operations ALTER TABLE can perform on a view?
IIRC, it can be used to
On Mon, 2006-10-09 at 12:02 -0400, Tom Lane wrote:
It's not clear to me why we have width_bucket operating on numeric and
not float8
I asked about this when I originally implemented width_bucket(), I
recall[1]. At the time, there was scepticism about whether it was even
worth implementing
On Mon, 2006-10-09 at 22:49 -0400, jungmin shin wrote:
Does anybody know what the Postgres does for optimizing the queries
with UDFs?
The optimizer considers function volatility to avoid reevaluating UDFs
needlessly, and to use index scans on predicates involving a function.
Also, functions
On Thu, 2006-10-05 at 12:52 -0400, Luke Lonergan wrote:
Create table as select ... Order by ...
Copy to ...
Or in 8.2, COPY TO (SELECT ... ORDER BY) (My, that's a neat feature.)
-Neil
---(end of broadcast)---
TIP 5: don't forget to increase
On Thu, 2006-10-05 at 14:53 -0400, Luke Lonergan wrote:
Is that in the release notes?
Yes: Allow COPY to dump a SELECT query (Zoltan Boszormenyi, Karel Zak)
-Neil
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore
On Tue, 2006-10-03 at 10:48 -0400, Tom Lane wrote:
I have no particular desire to introduce a version number check until we
have to. If you can show that the newer versions have a qsort that
substantially *out-performs* ours
Are there any platform-local variants of qsort() that substantially
On Tue, 2006-10-03 at 15:44 -0400, Tom Lane wrote:
I propose that we do the following:
1. Switch to using port/qsort.c all the time.
2. Add a qsort_arg function that is identical to qsort except it also
passes a void pointer through to the comparison function. This will
allow us to
On Tue, 2006-09-26 at 16:53 -0400, Tom Lane wrote:
strlcpy does more than we need (note that none of the existing uses care
about counting the overflowed bytes). Not sure if it's worth adopting
those semantics when they're not really standard, but if you think a lot
of people would be
On Mon, 2006-09-25 at 16:44 +0530, Gurjeet Singh wrote:
At the end of the following page:
http://www.postgresql.org/docs/8.0/static/indexes-partial.html
there is a link [Generalized Partial Indexes] which is pointing to a
missing link.
I agree the link should be fixed, but I can't see
On Mon, 2006-09-04 at 15:19 -0400, Tom Lane wrote:
AFAICT it's just junk. It happens to be the input times
MAX_RANDOM_VALUE, but what use is that? I wonder if we shouldn't
change the function to return VOID
I agree. Given how soon we want to get an 8.2 beta out the door, perhaps
this change
On Mon, 2006-09-18 at 14:10 -0400, Andrew Dunstan wrote:
My idea was to have a file called reserved_oids.h which would contain
lines like:
#error do not include this file anywhere
CATALOG(reserved_for_foo_module,9876) /* 2006-09-18 */
and which would be examined by the unused_oids
Tom Lane wrote:
ISTR that we had patch-merging problems too, because any patch
submitters who took it seriously were trying to patch the same chunk
of release.sgml.
That could be annoying, yes. I'm not sure how serious a problem it would
be in practice -- we could always adopt workarounds
Bruce Momjian wrote:
Also, we are having trouble getting enough people to review/commit.
Does adding an extra step discourage them even further?
I think if you are committing a patch, you should have a clear idea of
what the patch does and what its broader impact on the system will be.
Bruce Momjian wrote:
Another complexity is that when you are going through the logs in 1-3
days, you remember all the information and can adjust things so they are
consistent. I have certain rules of determining what items are worthy,
what are not, and what have to be merged into a single
Bruce Momjian wrote:
There are problems with this.
There are going to be problems with just about any proposal, but I think
updating the release notes incrementally is still a clear net win.
First, since everyone isn't going to do it, I still have to go
through all the CVS logs, and then I
Bruce Momjian wrote:
Robert Treat wrote:
FWIW I have never understood why we don't require patch submitters/committers
to update the release notes when they do the patch.
I've suggested this more than once in the past -- I think it would be a
clear improvement over the status quo. Updating
Martijn van Oosterhout said:
Ok, it looks like pages can be arranged hierarchically.
Well, a prefix like Todo: is not the incantation one needs to use to
arrange pages in hierarchies. You probably want / to indicate a subpage:
i.e. Parent/Child. See
On Mon, 2006-08-28 at 15:21 -0400, Tom Lane wrote:
We have more than enough problems to fix for 8.2 already. Let's
try to do this early in the 8.3 cycle instead.
I agree -- I think this is exactly the sort of change that is best made
at the beginning of a development cycle, so that there's a
On Mon, 2006-08-21 at 07:31 +0200, Hans-Juergen Schoenig wrote:
CREATE OR REPLACE FUNCTION xy() RETURNS SETOF record AS $$
SELECT relname::text, relpages::int4
FROM pg_class;
$$ LANGUAGE SQL IMMUTABLE;
As far as i remember inlined SQL code has been implemented into the
On Thu, 2006-08-10 at 17:33 -0700, Joshua D. Drake wrote:
No, like the rest of the world, Trac has moved on from CVS ;)
There is CVSTrac (www.cvstrac.org), which actually predates Trac.
However, is there a reason to use Trac beyond the fact that it is
already setup? ISTM we only need a wiki,
On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote:
Well, either people post the changes publically or I trust a few people.
I don't trust everyone or the TODO becomes a dumping ground, which I am
afraid might happen with a wiki that anyone can update.
I think that's preventable,
On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote:
While I am not going to reopen the can of worms labeled 'bug tracker',
I think it would be good to have a little more formality as far as
claiming items goes.
What say?
I think this is a good plan for adding additional process overhead,
On Fri, 2006-08-04 at 15:44 -0700, David Fetter wrote:
As far as the problem in need of solving, it's what Andrew Dunstan
referred to as splendid isolation, which is another way of saying,
letting the thing you've taken on gather dust while people think
you're working on it.
I'm just not
On Tue, 2006-08-01 at 07:55 -0700, Luke Lonergan wrote:
WRT hashing - we use FNV hash which is a very nice, very fast modern hash
algorithm. We would contribute that if we worked on this.
We currently use Bob Jenkins' hash function[1], which is apparently
faster than FNV on most architectures
On Tue, 2006-07-25 at 19:00 -0400, Tom Lane wrote:
Maybe I'm missing something, but I thought it was fairly common to use
k for 1000, K for 1024, etc (mnemonic: upper case for the larger
multiplier).
Well, that only works for K vs. k: the SI prefix for mega is M (meaning
10^6), not m.
On Thu, 2006-07-20 at 18:19 -0400, Tom Lane wrote:
About the best bet is to make sure that's the *only* available index,
and set enable_seqscan = off to be sure.
Another approach would be to define a UDF that takes a query string,
runs the parser, rewriter, and planner on the string and then
On Tue, 2006-07-18 at 14:35 -0400, Gregory Stark wrote:
My first thought would be a message like CancelQuery which would cause the
backend to peek into a static data structure and return a message that the
client could parse and display something intelligent.
I'm not quite sure what you're
On Tue, 2006-07-18 at 18:06 -0400, Phil Frost wrote:
I could really use a --view option to pg_dump (and pg_restore, i
imagine).
pg_dump -t view_name will work.
-Neil
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Mon, 2006-07-17 at 10:11 -0700, Josh Berkus wrote:
On the other hand, if we include PL/Perl, Tcl and Python but exclude Ruby
from the main package we are effectively making a statement to Ruby users
that their language is inferior in our consideration.
Hardly -- no more so than not
On Fri, 2006-07-14 at 14:20 -0400, Tom Lane wrote:
I would like to propose that we revert all the include-related changes
of the past two days, and that src/tools/pginclude be removed from the
CVS tree, until such time as it is rewritten to be much smarter about
what it is doing.
Rather than
On Sat, 2006-07-15 at 00:05 -0400, Tom Lane wrote:
The fundamental problem with find_static is that it hasn't got a clue
about likely future changes, nor about what we think external add-ons
might want
We could annotate the source to indicate that some functions are
deliberately intended to be
On Thu, 2006-07-13 at 00:50 -0400, Tom Lane wrote:
This has broken two out of the four buildfarm members that reported
in the last half hour :-( I think kudu does not like // comments,
not sure what kookaburra is on about.
BTW, you've switched your animal names :) I fixed the C++-style
On Tue, 2006-07-11 at 21:19 +0200, Chris Mair wrote:
One of the problems with this was that a user would expect psql to
work as usual (including all format and output option stuff) and
to do this properly most of the psql output code would need to be
refactored.
Even if the refactoring were
On Mon, 2006-07-03 at 23:28 -0400, Agent M wrote:
Why are only select, insert, update, and delete supported for $X binds?
This is a property of the way prepared statements are implemented.
Prepared statement parameters can be used in the place of expressions in
optimizeable statements (the
On Wed, 2006-07-05 at 06:55 -0400, Agent M wrote:
Like you said, it would make sense to have binds anywhere where there
are quoted strings- if only for anti-injection. There could be a flat
plan which simply did the string substitution with the proper escaping
at execute time.
I don't see
(1) The docs claim that pg_get_viewdef() returns the CREATE VIEW
command for view, but that is clearly not the case:
postgres=# create view v1 as select 1;
CREATE VIEW
postgres=# select pg_get_viewdef('v1'::regclass::oid);
pg_get_viewdef
SELECT 1;
(1 row)
Should we change the
101 - 200 of 1081 matches
Mail list logo
