On Thu, 2006-06-22 at 12:52 -0400, Andrew Dunstan wrote:
I believe our supported version is still 2.5.4, which is
what all my linux systems have.
Its not clear to me why some people have such antipathy toward recent
flex releases, but if our only supported flex version is 2.5.4, I think
this
On Wed, 2006-06-14 at 16:56 -0400, Bruce Momjian wrote:
The code churn to do this is going to be quite significant
Why do you say that? Although the original patch posted to implement
this was incomplete, it certainly wasn't very large.
-Neil
---(end of
On Fri, 2006-06-09 at 14:33 -0500, Jim C. Nasby wrote:
Currently, the only way to get a listing of tables in a schema via psql
is to modify your search_path, which is both non-intuitive and a PITA.
I've griped about psql's limited support for schemas in the past:
On Mon, 2006-06-05 at 19:17 +0200, Zoltan Boszormenyi wrote:
The general case cannot be applied for all particular cases.
E.g. you cannot use cursors from shell scripts
This could be fixed by adding an option to psql to transparently produce
SELECT result sets via a cursor.
-Neil
On Fri, 2006-06-02 at 09:56 -0400, Andrew Dunstan wrote:
Allow COPY to output from views
FYI, there is a patch for this floating around -- I believe it was
posted to -patches a few months back.
Another idea would be to allow actual SELECT statements in a COPY.
Personally I strongly
On Sat, 2006-04-15 at 21:24 +0100, Dave Page wrote:
one to allow a message to be sent with the notify, and one to move
from a table based design to shared mem/disk.
Doing the latter is a precondition for implementing the former in a
reasonable way, I believe.
BTW, these two web log entries
On Tue, 2006-04-11 at 17:20 -0400, Tom Lane wrote:
No, I'm saying that having access to a PL renders certain classes of
attacks significantly more efficient. A determined attacker with
unlimited time may not care, but in the real world, security is
relative.
That's a fair point.
Perhaps a
Two quick announcements:
(1) I'm planning on taking the summer off from Postgres development (May
til the end of August). I'll be temporarily unsubscribing from the
mailing lists, but I'll be accessible via personal email, so feel free
to CC me on anything you'd like my input on.
(2) I'll be on
On Thu, 2006-03-30 at 11:20 +1000, Philip Yarra wrote:
Hi folks, I've found that CVS HEAD psql's \c doesn't quite behave as expected
when postmaster is listening on non-default port.
I've committed a patch to HEAD that should improve this behavior. Let me
know if the current behavior is still
On Fri, 2006-03-31 at 20:27 -0500, Agent M wrote:
Why is the schema ignored entirely when using listen/notify?
Per the docs:
Commonly, the notification name is the same as the name of some
table in the database, and the notify event essentially means, I
changed this table, take a
On Thu, 2006-03-23 at 18:15 -0500, Tom Lane wrote:
Personally, I'd really like to have a local repository copy, because
I spend a *lot* of time with cvsweb etc --- but I'm sure my needs are
several standard deviations away from the mean.
I'm actually amazed that anyone does any serious amount
On Sun, 2006-03-19 at 17:14 -0500, Bruce Momjian wrote:
I see one in cash.c that I will remove.
I've already checked in a fix for that, as well as a few other places
that made similar mistakes -- sorry for stepping on your toes.
-Neil
---(end of
On Sat, 2006-03-18 at 22:36 +0900, Michael Glaesemann wrote:
Yes, there have been reports that it builds. You can check the
archives for details.
Are we prepared to declare that OS/X on Intel is an officially supported
platform for the 8.1 release series? If so, we should add that
information
On Sun, 2006-03-12 at 23:39 +0800, William ZHANG wrote:
Maybe you can fix it like UNIONJOIN.
Indeed, that is one option. Because the syntax is WITH [ LOCAL |
CASCADED ] CHECK OPTION, ISTM we'll actually need three new tokens:
WITH_LOCAL, WITH_CASCADED, and WITH_CHECK, which is even uglier :-(
On Fri, 2006-03-10 at 11:21 +0100, Bernd Helmle wrote:
Please find attached a patch that implements SQL92-compatible updatable
views.
I'm currently reviewing this. Comments later...
Please note that the patch isn't complete yet
Do you have a list of known TODO items?
-Neil
On Wed, 2006-03-08 at 07:47 -0800, David Fetter wrote:
From the earlier discussion, it appears that there is a variety of
opinions on what the COPY delimiter should be in pg_dump. This patch
allows people to set it and the NULL string.
I'm still not convinced there is a reasonable use-case
On Wed, 2006-03-08 at 08:20 -0800, David Fetter wrote:
The previous discussion showed that there is a wide diversity of
opinions on what The Right Delimiter and The Right NULL String(TM)
are.
Barring a more convincing justification for why we need this feature,
I'm inclined to side with Tom:
On Mon, 2006-03-06 at 11:55 -0300, Alvaro Herrera wrote:
AFAIR they got a private scan done and they fixed the reported defects.
Indeed: EnterpriseDB paid for a license for the Coverity static analysis
tool, and then ran that tool on the open-source Postgres tree. One of
their engineers then
On Wed, 2006-03-01 at 11:51 +0100, Peter Eisentraut wrote:
The PostgreSQL Anniversary Summit will take place on July 8 and 9, 2006, in
Toronto, Canada. We are planning for a gathering of about 50 hackers,
contributors, and other friends of the PostgreSQL project to celebrate the
project's
On Thu, 2006-03-02 at 17:23 -0500, Jonah H. Harris wrote:
If this is the consensus, then I'm fine with posting to -patches
Yeah, -patches is the right place.
I just want to make sure people are aware of it so it can get tested.
I wouldn't expect a whole lot of testing. The usual process is
The query optimizer currently does not consider reordering a query's
grouping columns. While the order in which ORDER BY columns are
specified affects the semantics of the query, AFAICS GROUP BY's column
order does not. Reordering a query's grouping columns would allow the
optimizer to avoid some
toast_compress_datum() considers compression to be successful if the
compressed version of the datum is smaller than the uncompressed
version. I think this is overly generous: if compression reduces the
size of the datum by, say, 0.01%, it is likely a net loss to use the
compressed version of the
Kevin Grittner wrote:
Peter Brant, a consultant working with us, has written code which is
working for this under both Linux and Windows. [...] For Linux, he
used statvfs.
statvfs(2) is standardized, but doesn't seem portable: it isn't
available on OSX 10.3, NetBSD 2.0 or OpenBSD, for
On Thu, 2006-02-16 at 12:35 +0100, Steinar H. Gunderson wrote:
glibc-2.3.5/stdlib/qsort.c:
/* Order size using quicksort. This implementation incorporates
four optimizations discussed in Sedgewick:
I can't see any references to merge sort in there at all.
stdlib/qsort.c defines
On Wed, 2006-02-15 at 18:28 -0500, Tom Lane wrote:
It seems clear that our qsort.c is doing a pretty awful job of picking
qsort pivots, while glibc is mostly managing not to make that mistake.
I haven't looked at the glibc code yet to see what they are doing
differently.
glibc qsort is
On Tue, 2006-02-14 at 22:54 +, Simon Riggs wrote:
On Tue, 2006-02-14 at 17:28 -0500, Tom Lane wrote:
IMHO the thing we are really seriously short of is patch reviewers.
[...]
Well that was the basis of my original suggestion. Publish some
guidelines and everybody becomes a patch reviewer.
On Wed, 2006-02-08 at 11:55 -0800, Josh Berkus wrote:
One justification for in-place upgrades is to be faster than
dump/reload. However, if we're assuming the possibility of new/modified
header fields which could then cause page splits on pages which are 90%
capacity, then this time
On Tue, 2006-02-07 at 19:45 -0400, Rodolfo Campos wrote:
I'm getting problems compiling a trigger written in C (exactly the one
from the documentation), when compiling it I get the errore shwoned
here.
This question belongs elsewhere (e.g. pgsql-general) -- -hackers is for
development-related
On Sun, 2006-02-05 at 14:03 +, [EMAIL PROTECTED] wrote:
3. Somehow create shared memory using the shmem functions, and set a memory
context to live *inside* this shared memory, which my trigger functions can
then switch to. Then use palloc() and pfree() without worrying..
This has been
On Fri, 2006-02-03 at 10:46 +0100, andrew wrote:
I am modifying the source code. I want to look up some information
from some tables while parsing the queries.
If you're referring to the raw parser (parser/gram.y), you should not
attempt to access any tables. For one thing, the raw parser might
On Tue, 2006-01-31 at 20:32 -0500, Rod Taylor wrote:
Perhaps a second database connection could be established during
situations when running tab completion and other psql commands is
impossible on the main one?
That would lead to inconsistencies, because of differences between the
two
While reviewing Joachim Wieland's patch to add a pg_cursors system view,
I noticed that the patch assumes that debug_query_string contains the
portion of the submitted query string that corresponds to the SQL
statement we are currently executing. That is incorrect:
debug_query_string contains the
On Mon, 2006-01-16 at 07:57 -0600, Andrew Dunstan wrote:
I too have done this. But retrofitting Doxygen style comments to the
PostgreSQL source code would be a big undertaking. Maintaining it, which
would be another task for reviewers/committers, would also be a pain unless
there were some
On Wed, 2006-01-11 at 02:58 -0500, Tom Lane wrote:
One comment is that there are worse things than small memory leaks in
seldom-followed code paths, especially if those paths are only taken in
error cases.
While I agree the problem isn't a showstopper, I think it is still
worthy of concern:
On Tue, 2006-01-10 at 09:47 -0500, Tom Lane wrote:
I had a further thought about this. What we're really talking about
here is a reference-counted TupleDesc structure: it's got no necessary
connection to TypeCacheEntry at all.
Yeah, I came to basically the same conclusion when implementing
While thinking about how to do memory management for the TupleDesc
refcounting changes, it occurred to me that this coding pattern is
dangerous:
local_var = MemoryContextAlloc(TopMemoryContext, ...);
func_call();
/* ... */
/* update global state */
if (global != NULL)
pfree(global);
global =
On Sun, 2006-01-08 at 20:04 -0500, Tom Lane wrote:
On reflection I think that lookup_rowtype_tupdesc is simply misdesigned.
We can't have it handing back a pointer to a data structure of unspecified
lifetime. One possibility is to give it an API comparable to the
syscache lookup functions, ie
On Mon, 2006-01-09 at 20:23 +0100, Thomas Hallgren wrote:
Should I consider this as something to add to the PL/Java TODO list?
Probably, yes (if/when I fix the in-tree PLs I was planning to take a
look at all the externally-maintained ones, although you're welcome to
do it instead).
Before
On Mon, 2006-01-09 at 12:57 -0500, Tom Lane wrote:
I have not been able to think of an efficient way to make it work while
still handing back a simple TupleDesc pointer --- seems like we'd have
to contort the API somehow so that the release function can find the
reference count. Any thoughts
On Mon, 2006-01-09 at 14:51 -0500, Tom Lane wrote:
Nah, I don't think this works. The problem is that after an inval,
you may have to provide an updated TupleDesc to new callers while
old callers still have open reference counts to the old TupleDesc.
Good point.
However, you might be able
Christopher Kings-Lynne wrote:
I hope you mean 'redundant with PRIMARY KEY in example'...
Why? SERIAL implies NOT NULL (although PRIMARY KEY does as well, of course).
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
I'd like to take a look at fixing the fact that procedural languages do
not check the constraints associated with domain types. I think there
are two separate issues:
(1) In PL/PgSQL, we need to check domain constraints whenever we assign
a new value to a variable of a domain type.
(2) When
On Tue, 2005-12-13 at 22:32 +0100, Joachim Wieland wrote:
there's a topic that comes up from time to time on the lists, the problem
that pgsql functions get planned only once and thereafter the same query
plan is used until server shutdown or explicit recreation of the function.
The problem
On Mon, 2005-12-12 at 11:50 -0500, Bruce Momjian wrote:
Are you willing to say that we should always prefer pgport over glibc's
qsort()?
glibc's qsort is actually implemented via merge sort. I'm not sure why
the glibc folks chose to do that, but as a result, it's not surprising
that BSD qsort
On Mon, 2005-12-12 at 16:19 -0500, Tom Lane wrote:
It seems that gcc is up to some creative reinterpretation of basic C
semantics again; specifically, you can no longer trust that traditional
C semantics of integer overflow hold:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175462
On Wed, 2005-11-30 at 10:56 -0500, Tom Lane wrote:
It's been about a month since 8.1.0 was released, and we've found about
the usual number of bugs for a new release, so it seems like it's time
for 8.1.1.
I think one fix that should be made in time for 8.1.1 is adding a note
to the version
There are currently some rather crude knobs for persuading the planner
to favour certain kinds of query plans: the enable_XXX GUC variables.
Several people have asked for a more flexible way to give hints to the
planner. I'm not interested in implementing fully-general planner hints
at the moment,
On Thu, 2005-12-01 at 18:33 +0800, Christopher Kings-Lynne wrote:
36.7.3.5. FOR (integer variant)
In the 8.1 docs. Label has been spelt Labal.
Thanks, fixed in HEAD and REL8_1_STABLE.
-Neil
---(end of broadcast)---
TIP 1: if posting/reading
On Thu, 2005-12-01 at 16:38 -0500, Bruce Momjian wrote:
Maybe it should be:
errno = 0; /* Allow unconditional errno check */
I think any solution that involves adding more duplication at each
strtol() callsite is not great (Don't Repeat Yourself). I'd still like
to see this
On Thu, 2005-12-01 at 21:01 -0500, Gregory Maxwell wrote:
If we'd really like to avoid people using the knobs to rig queries,
how about making them only work with explain analyze, useful for
debugging but not so useful for actual queries.
That seems a pretty arbitrary limitation. I agree that
On Thu, 2005-10-11 at 15:22 -0300, Gustavo Tonini wrote:
how can i make a checkout from CVS server ? What is the address?
http://www.postgresql.org/developer/sourcecode/
-Neil
---(end of broadcast)---
TIP 4: Have you searched our list archives?
On Mon, 2005-07-11 at 20:39 +0530, Sreejesh O S wrote:
How can I access CVS ?
http://www.postgresql.org/developer/sourcecode/
Please try to do at least a little research before posting.
-Neil
---(end of broadcast)---
TIP 5: don't forget to
On Mon, 2005-07-11 at 09:19 -0300, Alvaro Herrera wrote:
I have another gripe regarding pgindent. Why does it change indenting
of function declarations?
On a related note, most of these changes are completely bogus:
On Tue, 2005-25-10 at 17:43 -0400, Tom Lane wrote:
What I suggest we do about this is change addImplicitRTE() to set
inFromCl true for implicitly added RTEs, so that the view rule will
later be dumped as if the query had been written per spec.
Sounds reasonable. I wonder if this should be
On Mon, 2005-17-10 at 16:48 -0500, Jim C. Nasby wrote:
Sorry if I'm just confused here, but don't LWLocks protect data
structures susceptible to corruption? And if that's the case don't we
need to be sure that the compiler can't optimize around them?
LWLocks certainly do protect shared data,
On Mon, 2005-17-10 at 13:32 -0400, Tom Lane wrote:
I dislike portability approaches that try to enumerate supported cases,
rather than being general in the first place.
Do we need to have this on every platform we support? The symbols we
want to hide are internal by convention anyway -- using a
On Sun, 2005-16-10 at 01:20 -0700, Kevin McArthur wrote:
Don't forget insert/update returning.
Omar Kilani has a patch for this:
http://archives.postgresql.org/pgsql-patches/2005-07/msg00568.php
I would like to see it get into 8.2
-Neil
---(end of
On Fri, 2005-14-10 at 13:08 +0100, Dave Page wrote:
Note that when we moderate this we now hide away most of the comments
that may suggest improvements for the docs and only leave the ones that
are actually helpful in their own right visible.
If someone wants access to these to review, please
On Wed, 2005-12-10 at 22:46 -0400, Tom Lane wrote:
No --- we didn't have any per-buffer spinlocks before 8.1.
Right. To summarize the problem as I understand it: we need to force $CC
not to move loads and stores around spinlock acquire/release. This can't
be done by just marking the spinlock
On Wed, 2005-12-10 at 23:46 -0400, Bruce Momjian wrote:
Agreed. I have changed them both to stable. I think xslt_process()
should be stable because it is unlikely you would want a URL's contents
to change inside a transaction
Why is it unlikely?
If a function's return value for a particular
On Mon, 2005-10-10 at 15:57 -0400, Lane Van Ingen wrote:
That sounds good, and about what I expected. I am not a C programmer, but
have access to others who are. Where would I need to put the C function
in order to have PostgreSQL find it? Any special considerations
other than putting it in
Tom Lane said:
But I think you might be confusing that with the feature-or-bug
(depending on one's point of view) that duplicate notifications can be
merged into one event. I'm inclined to preserve that behavior,
primarily because not doing so would create a tremendous penalty on
On Sat, 2005-08-10 at 00:42 +0530, sandeep satpal wrote:
... please guide me
Two suggestions:
(1) Don't start new threads by replying to an existing thread of no
relevance to the new subject
(2) Spend some time phrasing your question in a coherent manner --
you're more likely to get a useful
On Thu, 2005-06-10 at 23:56 -0400, Bruce Momjian wrote:
True, but are people going to recompile PostgreSQL to use this feature?
Seems they would have to.
They would need to recompile PostgreSQL to use more than the default
number of user-defined LWLocks, which seems perfectly reasonable to me.
Applications that frequently use LISTEN/NOTIFY can suffer from
performance problems because of the MVCC bloat created by frequent
insertions into pg_listener. A solution to this has been suggested in
the past: rewrite LISTEN/NOTIFY to use shared memory rather than system
catalogs.
The problem is
On Thu, 2005-06-10 at 01:14 -0400, Tom Lane wrote:
The idea of blocking during commit until shmem becomes available might
work. There's some issues here about transaction atomicity, though:
how do you guarantee that all or none of your notifies get sent?
(Actually, supposing that the notifies
On Fri, 2005-30-09 at 17:47 -0500, Jim C. Nasby wrote:
What's wrong with adding pg_cancel_backend(...) RETURNS int as an alias
for the one that returns boolean, and document that it's deprecated and
will be removed in the future.
You can't overload functions based on their return type alone.
On Wed, 2005-28-09 at 18:35 -0300, Marc G. Fournier wrote:
The problem isn't whether or not they should be changed, the problem is
that they were changed *during* beta AND *against* the direction that
discussion on these changes went
I'm not sure what you mean: what is the direction that
On Mon, 2005-19-09 at 16:27 +0200, Hans-Jürgen Schönig wrote:
I was wondering whether it is possible to teach the planner to handle
DISTINCT in a more efficient way:
[...]
Isn't it possible to perform the same operation using a
HashAggregate?
One problem is that DISTINCT ON is defined to
On Mon, 2005-19-09 at 10:57 -0400, Tom Lane wrote:
Any change like that would require another initdb. If we were going to
force another initdb, my vote would be to revert these functions to
where they were in beta1.
What purpose would that serve? About the only thing purpose I can see is
to
On Sat, 2005-17-09 at 14:47 +0200, Magnus Hagander wrote:
Also, the change to pg_cancel_backend breaks backwards compatibility
with 8.0, which is a whole lot worse than breaking it with 8.1-beta1.
Yeah, I thought about that (and Bruce and I already discussed it offlist
before I committed the
On Fri, 2005-16-09 at 08:47 +0100, Dave Page wrote:
Perhaps you could allow 24 hours before committing potentially
controversial changes in future?
My apologies for the rush -- I normally would wait longer for a
consensus. In fact, I _was_ waiting for a consensus until I saw that the
wrap for
On Thu, 2005-15-09 at 21:09 -0300, Marc G. Fournier wrote:
Tomorrow afternoon, we are planning on packaging up Beta2 .. if anyone is
sitting on something that should get in before that happens, or has a bug
they are sitting on, please let us know ...
One change that I would like to get into
On Thu, 2005-15-09 at 22:31 -0400, Tom Lane wrote:
I thought we'd more or less dropped that idea based on Andreas'
responses.
I've heard no argument against renaming pg_complete_relation_size() to
pg_total_relation_size() and changing the functions that return an
integer status code to make
On Thu, 2005-15-09 at 22:06 -0400, Neil Conway wrote:
One change that I would like to get into beta2 is the proposed
refactoring of some of the new system info / administration functions.
Ok, this is done: the changes have been committed to CVS HEAD and the
catalog version number has been
Tom Lane wrote:
I agree with both of those criticisms: total is more in line with our
nomenclature than complete, and the other functions should return void
and ereport when they are unhappy. (Saying I failed and not having
any mechanism to report why sucks.)
From reading the code, it
Two minor gripes about these new functions:
(1) I think pg_total_relation_size() is a bit more concise and clear
than pg_complete_relation_size().
(2) pg_cancel_backend(), pg_reload_conf(), and pg_rotate_logfile() all
return an int indicating success (1) or failure (0). Why shouldn't these
Tom Lane wrote:
If we weren't already forcing an initdb for beta2, I'd say it's a bit
late to be complaining ... but we can fix them for free right now,
so why not?
Ok, I'll take a look.
While we're on the subject, the units used by pg_size_pretty() are
incorrect, at least according to the
Tom Lane wrote:
[ itch... ] The IEC may think they get to define what's correct, but
I don't think that squares with common usage. The only people who
think MB is measured in decimal are disk-manufacturer marketroids.
Well, just them and the IEEE :)
While common usage has been to use kB to
Bruno Wolff III wrote:
I ran accross an article a few weeks ago that suggested that this wasn't
all that great of an idea. Using HTML 4.01 should be just as useful.
Is there a reason why the FAQ can't be in DocBook, like the rest of the
documentation? That would allow multiple output formats
Tom Lane wrote:
Yeah. This is not really Slony's fault --- we need a general solution
to that in the backend. I think Neil was working on it, but I dunno
how far along he is.
Yeah, I had wanted to get this into 8.1, but I couldn't find time. I
still plan to work on it for 8.2, unless
For the past 11 months or so[1], I've been working full-time on
PostgreSQL as an employee of Fujitsu Australia Software Technology. I'm
grateful to Fujitsu for giving me this opportunity, and I've enjoyed the
past year. However, I'm returning to university in the fall, and
therefore I will no
Michael Fuhr wrote:
Can anybody else reproduce the problem?
I couldn't repro it, on x86 / Debian unstable / gcc 3.4.4, with current
CVS sources.
-Neil
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Gavin Sherry wrote:
list_add() doesn't really describe what it does.
I agree -- the functionality itself is fine, of course, but it would be
nice to have a better name.
I was thinking either list_cond_add() or list_merge().
What about list_append_distinct()? (And
Tom Lane wrote:
How about list_append_distinct and list_concat_distinct?
Those names are fine with me.
-Neil
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On 7/18/05 5:13 AM, Andrew Dunstan [EMAIL PROTECTED] wrote:
I was told, quite possibly incorrectly, and I forget by whom, that the 1
hour delay didn't apply to CVSup.
I think that might have been me -- if you're syncing from
mcvsup.postgresql.org, there should be no delay.
-Neil
Christopher Kings-Lynne wrote:
Would it be useful to have a pg_get_prepared(name) function that returns
true or false depending on whether or not there is a prepared query of
that name?
From the TODO:
* Allow pooled connections to list all prepared queries
So this has been raised before.
David Fetter wrote:
As background, I'd like to go over our policy of, The code patch must
be accompanied by any doc patches that it implies.
Although it is worth noting this policy is not religiously followed
anyway (e.g. the recent roles patch). I think we basically assume that
the person
Victor Yegorov wrote:
Compiling HEAD I see the following 2 warnings:
bison -y -d preproc.y
mv -f y.tab.c ./preproc.c
mv -f y.tab.h ./preproc.h
/usr/bin/flex -o'pgc.c' pgc.l
gcc -O2 -ggdb -DBITMAP_DEBUG -Wall -Wmissing-prototypes -Wpointer-arith
-Wendif-labels -fno-strict-aliasing -g
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list
That is not the latest version of Marko's patch. But in any case, the
patch is not yet ready for application:
http://archives.postgresql.org/pgsql-patches/2005-07/msg00077.php
-Neil
Marko Kreen wrote:
On Sun, Jul 03, 2005 at 07:54:47AM -0600, Michael Fuhr wrote:
In the functions marked STRICT, should I leave the PG_ARGISNULL()
checks in place as a precaution? Removing those checks could cause
problems if people use the new code but have old (non-STRICT) catalog
entries.
Michael Fuhr wrote:
But if they restore a dump made with pg_dump or pg_dumpall, they'll
get the old catalog entries sans STRICT, no? People might rebuild
the module when they upgrade, but they might not think to drop and
recreate the functions since the definitions are already in the
dump.
I
Pavel Stehule wrote:
this patch allows optional using label with END and END LOOP. Ending label
has only informational value, but can enhance readability large block and
enhance likeness with Oracle.
Reviewed and applied -- thanks for the patch.
-Neil
---(end of
Bruce Momjian wrote:
I realize this needs review, but I will put it the queue so we don't
forget it.
The patch does not need review, as it doesn't even attempt to fix the
problem. (I just wrote the patch while analyzing the problem to make the
error condition more easily reproduceable). I
Pavel Stehule wrote:
this patch allows optional using label with END and END LOOP. Ending label
has only informational value, but can enhance readability large block and
enhance likeness with Oracle.
mainLOOP
...
...
END LOOPmain;
Attached is a revised version of this patch. Changes /
A coworker of mine reported a subtle issue in ATExecAlterColumnType() in
tablecmds.c. Suppose we have the following DDL:
CREATE TABLE pktable (a int primary key, b int);
CREATE TABLE fktable (fk int references pktable, c int);
ALTER TABLE pktable ALTER COLUMN a TYPE bigint;
Circa line 4891 in
innodb wrote:
Currently I want to take a TPC-H test on postgresql-8.0.2.
You might want to take a look at the TPC-H implementation here:
http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite/osdl_dbt-3/
-Neil
---(end of
Jonah H. Harris wrote:
I don't recommend discussion for this in this thread, but it could also
tie in with the packages support we've discussed and (although some may
argue this), compiling the PL to bytecode and using that.
How would compilation to bytecode help?
-Neil
Jan Wieck wrote:
The whole parser is a hack that attempts to parse the procedural parts
of the function but preserving the SQL parts as query strings while
substituting variables with numbered parameters. That is anything but
clean. It was the only way I saw at the time of implementation to
Peter Eisentraut wrote:
It is required by the SQL standard.
No, it isn't -- PL/PgSQL is not defined by the SQL standard. I guess
you're referring to SQL/PSM, but that has only a passing resemblance to
PL/PgSQL. Implementing SQL/PSM in some form would definitely be worth
doing (especially
201 - 300 of 1081 matches
Mail list logo
