> 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 TO
Would anybody object to a patch to update psql's tab completion for
SET/RESET/SHOW to include everything that SHOW shows for a superuser?
I count about 65 variables that SHOW shows that are missing from
pgsql_variables in tab-complete.c. Does the list intentionally
omit certain variables? The co
On Fri, Aug 12, 2005 at 09:53:59PM -0400, Bruce Momjian wrote:
>
> Can I have a TODO item for this?
Something like "ease dropping roles which have dependencies spilt over
several databases" ... ?
> Alvaro Herrera wrote:
> > On Sat, Jul 30, 2005 at 12:19:41AM -0400, Bruce Momjian wrote:
> >
> >
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Please keep that URL active or send us the patch to the patches list.
Thanks.
---
yuanjia lee wrote:
>
> Hi All
>
> I
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Matteo Beccati wrote:
> Hi,
>
> >>Moving it in contrib/ltree would be more difficult to me because it
> >>depends o
Folks, we need to address the questions asked in this email and get it
into CVS soon.
---
Magnus Hagander wrote:
> I just realised this mail didn't go through. Probably because it was too
> large for -hackers. So: repost to
Where are we going with this patch? It doesn't test specific OS's known
to fail.
---
Marko Kreen wrote:
> On Thu, Aug 04, 2005 at 08:14:51PM +0200, Stefan Kaltenbrunner wrote:
> > Tom Lane wrote:
> > >Andrew Dunstan <[EMAIL
I am not sure it was reported to you but this has been corrected:
test=> CREATE TABLE test(id SERIAL NOT NULL);
NOTICE: CREATE TABLE will create implicit sequence "test_id_seq" for
serial column "test.id"
CREATE TABLE
test=> ALTER TABLE TEST OWNER TO test
Should this functionality be moved into the backend? When?
---
Tatsuo Ishii wrote:
> > On Fri, Aug 12, 2005 at 02:08:29PM +0900, Tatsuo Ishii wrote:
> > > > On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
> >
Interesting. Are you sure all those processes were using our standard
flags? Seems unusual and you are right, it shouldn't be happening.
---
Qingqing Zhou wrote:
>
> ""Magnus Hagander"" <[EMAIL PROTECTED]> writes
> >
> > I
Any comments on this idea?
---
Tom Lane wrote:
> I wrote:
> > This does not look real easy to fix. Who's up for reimplementing
> > gettext and a few other pieces from scratch?
>
> However, I did find
>
> http://gnu.misce
Brendan Jurd wrote:
> 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, an
I have applied everything reasonable that was in the patch queue. The
remaining items need attention and comments..
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts R
Right, fixed in create_table.sgml. I don't think it is any other place.
---
Alvaro Herrera wrote:
> The CREATE TABLE synopsis shows this:
>
> CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE table_name (
> { colum
Can I have a TODO item for this?
---
Alvaro Herrera wrote:
> On Sat, Jul 30, 2005 at 12:19:41AM -0400, Bruce Momjian wrote:
>
> > I have just loaded the patches list with all outstanding patches that
> > need consideration,
Tom Lane wrote:
> "Dave Page" writes:
> > However In all but one place in libpq, we don't use errno anyway
> > (actually 2, but one is a bug anyway) because we use GetLastError()
> > instead (which tested thread safe as well FWIW). The only place it's
> > used is PQoidValue():
>
> > resul
Definitely should be released without it ... it is an extension not
submitted for inclusion prior to the feature freeze ...
On Fri, 12 Aug 2005, Alvaro Herrera wrote:
I'm working on the promised DROP OWNED patch, and just noticed that it
needs modifications to the Grant/Revoke machinery that
Tom Lane wrote:
> Bruce Momjian writes:
> > Patch applied. Thanks.
> > * block is not currently in memory.
> > */
> > bufHdr = BufferAlloc(reln, blockNum, &found);
> > + /* we are guaranted that nobody else has touched this
> > will-be-new block */
Bruce Momjian writes:
> Patch applied. Thanks.
>* block is not currently in memory.
>*/
> bufHdr = BufferAlloc(reln, blockNum, &found);
> + /* we are guaranted that nobody else has touched this
> will-be-new block */
> + Asser
Bruce Momjian writes:
> Patch applied. Thanks. If we made plpython worse, we will hear about
> it soon enough.
You did, and you're hearing about it. Please revert the
plpython/Makefile change; it is certainly wrong for every other
platform. What's more, it's unnecessary given the port makefil
I'm working on the promised DROP OWNED patch, and just noticed that it
needs modifications to the Grant/Revoke machinery that are too invasive
to consider for 8.1; the problem is that ExecuteGrantStmt takes textual
names for objects and grantees, and what I have from pg_shdepend are
Oids. Dropping
Patch applied. Thanks.
---
Qingqing Zhou wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> writes
> >
> > WARNING: relation "t1" page 196 is uninitialized --- fixing
> > TRAP: FailedAssertion("!PageHeader) ((PageHeader)
> pa
Patch applied. Thanks.
---
David Fetter wrote:
> On Sat, Jul 30, 2005 at 09:47:58AM -0400, Andrew Dunstan wrote:
> >
> >
> > David Fetter wrote:
> >
> > You have rolled 2 problems into one - spi_query+spi_fetchrow does
Martijn van Oosterhout writes:
> On Fri, Aug 12, 2005 at 09:56:47AM +0200, Martijn van Oosterhout wrote:
>> Ok, here's a patch (with documentation update). I checked the
>> regression tests (looked over, not run) but nothing there appears to
>> test this anyway. I looked through all the datatype i
Tom Lane wrote:
> Bruce Momjian writes:
> > Patch applied. Thanks. If we made plpython worse, we will hear about
> > it soon enough.
>
> You did, and you're hearing about it. Please revert the
> plpython/Makefile change; it is certainly wrong for every other
> platform. What's more, it's unne
Patch applied. Thanks.
I also added a comment above each one to mention why it is needed.
---
Gavin Sherry wrote:
> On Wed, 27 Jul 2005, Tom Lane wrote:
>
> > Gavin Sherry <[EMAIL PROTECTED]> writes:
> > > I ran across t
Patch applied. Thanks. If we made plpython worse, we will hear about
it soon enough. The freebsd-specific changes seem safe, considering
they came from the FreeBSD port maintainers themselves.
---
Jim C. Nasby wrote:
> O
The CREATE TABLE synopsis shows this:
CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE table_name (
{ column_name data_type [ DEFAULT default_expr ] [ column_constraint [ ... ] ]
| table_constraint
| LIKE parent_table [ { INCLUDING | EXCLUDING } DEFAULTS ] } [, ... ]
)
However,
On Thu, 11 Aug 2005 22:11:42 -0400 (EDT)
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > >> O_DIRECT is only being used for WAL page writes (or I sure hope so
> > >> anyway), so shared_buffers should be irrelevant.
> >
> > > Uh, O_DIRECT really just enables when open_sync i
"William ZHANG" <[EMAIL PROTECTED]> writes:
> Why not change the option "createuser" to "superuser",
Backwards compatibility with existing dump files.
> or do something to make is easier to understand?
See
http://developer.postgresql.org/docs/postgres/sql-createrole.html
SUPERUSER
NOSUPERUSER
> On Fri, Aug 12, 2005 at 02:08:29PM +0900, Tatsuo Ishii wrote:
> > > On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
> > >
> > > > However even one of transactions, for example 647 commits, still it
> > > > shows as if 647 is a member of muitixid 3.
> > > >
> > > > test=# select *
On Fri, Aug 12, 2005 at 18:11:54 +0800,
William ZHANG <[EMAIL PROTECTED]> wrote:
> "create user foo with createdb" will create a user with createdb privilege.
> "create user bar with createuser" will create s superuser who can createdb,
> createuser, and update system catalog.
>
> Why not change
"create user foo with createdb" will create a user with createdb privilege.
"create user bar with createuser" will create s superuser who can createdb,
createuser, and update system catalog.
Why not change the option "createuser" to "superuser", or do something
to make is easier to understand?
--
I find the comments in initsplan.c as following.
/*
* Presently the executor cannot support FOR UPDATE/SHARE marking of
* rels appearing on the nullable side of an outer join. (It's
* somewhat unclear what that would mean, anyway: what should we
* mark when a result row is generated
Forgot to attach it, oops.
On Fri, Aug 12, 2005 at 09:56:47AM +0200, Martijn van Oosterhout wrote:
> Ok, here's a patch (with documentation update). I checked the
> regression tests (looked over, not run) but nothing there appears to
> test this anyway. I looked through all the datatype input func
On Fri, Aug 12, 2005 at 02:08:29PM +0900, Tatsuo Ishii wrote:
> > On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
> >
> > > However even one of transactions, for example 647 commits, still it
> > > shows as if 647 is a member of muitixid 3.
> > >
> > > test=# select * from pgrowlock
Tom Lane wrote:
Kim Bisgaard <[EMAIL PROTECTED]> writes:
I have noticed a deficiency in the current query optimizer related to
"full outer joins". Tom Lane has confirmed to me that it will not be 8.1
material.
... There
are related issues involving N-way joins that we'
On Thu, Aug 11, 2005 at 02:51:11PM -0400, Tom Lane wrote:
> > Would a patch to change the rules be accepted, or would it be
> > considered a unnecessary backward incompatable change?
>
> I wouldn't back-patch it, but it seems like something we could still put
> in for 8.1.
Ok, here's a patch (wit
38 matches
Mail list logo
