Hi,
I was using OidInputFunctionCall() to cast a basic type into a domain
type. But when I saw
/*
* As above, for I/O functions identified by OID. These are only to be
* used in seldom-executed code paths. They are not only slow but leak
* memory.
*/
Datum
OidInputFunctionCall(Oid
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Well, the other issue is how many canned breakup schemes we are going to
support. If this particular one is of sufficiently general usefulness
then I have no objection. But when you can produce it trivially from the
Josh Berkus josh@agliodbs.com writes:
On the other hand, a lot of my personal dislike of BugZilla seems to be
based on being forced to use old versions. A lot of the stuff I hate
about it has been fixed in the current version.
Does that include it being basically a web-only interface?
Andrew Dunstan [EMAIL PROTECTED] writes:
stark wrote:
So I hacked psql to issue queries asynchronously and allow multiple
database connections. That way you can switch connections while a blocked
or slow transaction is still running and issue queries in other
transactions.
[snip]
I expect if you set up a web-based interface it won't be a matter of people
digging in heels so much as just being indifferent to it. And like most
projects the bugs will just accumulate and not get feedback.
And which projects would these be? Oddly enough it might surprise you
that the
Bruce Momjian [EMAIL PROTECTED] writes:
True. They could even put it in .psqlrc if they want. Basically need a
way to modify \g. Seems a \set is the way we have always done such
modifications in the past. The big question is whether this is somehow
different. Personally, I don't think so.
Gregory Stark [EMAIL PROTECTED] writes:
I'm listed on various mozilla bugs and occasionally get notifications of
updates but I can't reply to those notifications and I'm not about to fire up
a browser and log in and search for the bug just to add comments.
It's really not that painful: every
Volkan YAZICI [EMAIL PROTECTED] writes:
I was using OidInputFunctionCall() to cast a basic type into a domain
type.
Is this the right way to use domain_in() function?
If you're doing it more than about once per SQL command, you should find
a place to cache the fmgr lookup info and use
We have still another complaint here:
http://archives.postgresql.org/pgsql-bugs/2006-08/msg00109.php
about pg_dump failing to cope nicely with any slightly-unusual
condition related to a SERIAL column. We've had previous
discussions about this, most recently this thread:
On Sat, Aug 19, 2006 at 11:47:39AM -0400, Tom Lane wrote:
ALTER SEQUENCE foo_bar_seq SERIAL FOR foo.bar;
I like it, and I imagine users will love it too. Only one question:
will a sequence be limited to belonging to one table at a time, or
could you use one sequence for multiple tables and use
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Aug 19, 2006 at 11:47:39AM -0400, Tom Lane wrote:
ALTER SEQUENCE foo_bar_seq SERIAL FOR foo.bar;
I like it, and I imagine users will love it too. Only one question:
will a sequence be limited to belonging to one table at a time, or
Gregory Stark wrote:
Josh Berkus josh@agliodbs.com writes:
On the other hand, a lot of my personal dislike of BugZilla seems to be
based on being forced to use old versions. A lot of the stuff I hate
about it has been fixed in the current version.
Does that include it being
I wrote:
Also, after thinking about the existing behavior of ALTER TABLE OWNER
(it tries to keep ownership of dependent sequences equal to the table's
ownership), we'd have to either abandon that or insist that you can
only link a sequence to a table having the same owner. So that's
another
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
I'm listed on various mozilla bugs and occasionally get notifications of
updates but I can't reply to those notifications and I'm not about to fire up
a browser and log in and search for the bug just to add comments.
It's
Tom Lane wrote:
Basically this change would mean that you'd be allowed to DROP the
sequence with CASCADE (hence removing all the DEFAULT expressions that
use it) without being forced to drop the owning column as such. That
seems to square better with the idea that the column owns the
Bruce Momjian [EMAIL PROTECTED] writes:
Our two SERIAL TODO items are:
* %Disallow changing DEFAULT expression of a SERIAL column?
This should be done only if the existing SERIAL problems cannot be
fixed.
* %Disallow ALTER SEQUENCE changes for
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Our two SERIAL TODO items are:
* %Disallow changing DEFAULT expression of a SERIAL column?
This should be done only if the existing SERIAL problems cannot be
fixed.
* %Disallow ALTER SEQUENCE
Bruce Momjian [EMAIL PROTECTED] writes:
The only complaint I can see is that someone
who wants pg_dump to dump out SERIAL so it appears just as he created
the table, doesn't get that. Could we have pg_dump do that if the
sequences all match the creation (weren't modified)?
pg_dump's output
So I was fooling with making serial sequences be auto rather than internal
dependencies of their columns, and the regression tests blew up on me:
*** ./expected/dependency.out Mon Nov 21 07:49:33 2005
--- ./results/dependency.outSat Aug 19 17:46:55 2006
***
*** 109,113
---
I wrote:
I will check about Greg's complaint about race conditions in updating
comments. My initial impression is that this is no longer so, but I
will get a definite answer.
My impression was correct. Each comment on a bug gets its own row,
marked by bug-id, commenter-id and
Tom Lane wrote:
I think a correct solution probably requires making a list of all
objects to delete by scanning pg_shdepend and then starting to
delete 'em, using the list as oktodelete context similar to the
way that dependency.c handles auto/internal objects.
Hum. I'll take a look at
Tom Lane wrote:
I think a correct solution probably requires making a list of all
objects to delete by scanning pg_shdepend and then starting to
delete 'em, using the list as oktodelete context similar to the
way that dependency.c handles auto/internal objects.
What I'm considering is this:
OTRS was recommended to me as a bug tracker. Has anyone used that?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
Peter Eisentraut wrote:
OTRS was recommended to me as a bug tracker. Has anyone used that?
Not me, but I see that they use bugzilla for bug tracking ... see
http://bugs.otrs.org/index.cgi
cheers
andrew
---(end of broadcast)---
TIP 3: Have you
Alvaro Herrera [EMAIL PROTECTED] writes:
What I'm considering is this: scan pg_shdepend looking for objects to
delete, and save them into a list; but each time we find one, we also
find objects that depend on it. Those dependent objects should be
ignored; but we should also remove from the
Peter,
On 8/19/06 5:37 PM, Peter Eisentraut [EMAIL PROTECTED] wrote:
OTRS was recommended to me as a bug tracker. Has anyone used that?
We use OTRS for customer issue tracking, but we use Jira from Atlassian for
our internal bug tracking. We also use Confluence and Fisheye from
Atlassian,
[EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
OTRS was recommended to me as a bug tracker. Has anyone used that?
Not me, but I see that they use bugzilla for bug tracking ... see
http://bugs.otrs.org/index.cgi
And according to their front page, the preferred database behind it
is mysql.
27 matches
Mail list logo
