On Thu, 25 Jan 2007, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > I was talking to AndrewSN on irc about this. He proposed that we supply
> > two versions (yes I hear the collective groan) of the SQL functions: a
> > fast one (SnapshotNow) and an accurate one (which doesn't use
>
On Wed, 24 Jan 2007, Tom Lane wrote:
> In detail, it'd look something like:
>
> * For an untrusted language: must be superuser to either create or use
> the language (no change from current rules). Ownership of the
> pg_language entry is really irrelevant, as is its ACL.
>
> * For a trusted langu
Gavin Sherry <[EMAIL PROTECTED]> writes:
> I was talking to AndrewSN on irc about this. He proposed that we supply
> two versions (yes I hear the collective groan) of the SQL functions: a
> fast one (SnapshotNow) and an accurate one (which doesn't use
> SnapshotNow).
Um, that's such a fundamental
On Wed, 24 Jan 2007, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > FAST PostgreSQL wrote:
> >> Please find attached the patch with modifications
>
> > are you proposing to implement the other functions in this TODO item
> > (pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(
On Thu, 25 Jan 2007, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> ... convincing use-case that will justify the maintenance load we
> >> are setting up for ourselves. "Somebody might want this" is not
> >> adequate.
>
> > I realize it is problem to have the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... convincing use-case that will justify the maintenance load we
>> are setting up for ourselves. "Somebody might want this" is not
>> adequate.
> I realize it is problem to have the function in two places in our code,
> but if we do
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > FAST PostgreSQL wrote:
> >> Please find attached the patch with modifications
>
> > are you proposing to implement the other functions in this TODO item
> > (pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
> > pg_get_table
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Mag
Patch applied. Thanks.
---
Jaime Casanova wrote:
> On 1/20/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Patch withdrawn by author; corrected version expected.
> >
>
> new version of Albert's patch with PGC_USERSE
Patch applied. Thanks.
---
Guido Goldstein wrote:
> Hi!
>
> The attached patch fixes a bug in plpython.
>
> This bug was found while creating sql from trigger functions
> written in plpython and later running the generat
Patch applied. Thanks.
Docs updated to mention Win32:
Write the output to the specified file. This is particularly useful
on Windows because output redirection does not work for child
processes.
--
Patch applied. Thanks.
---
Dave Page wrote:
> Tom Lane wrote:
> > Dave Page <[EMAIL PROTECTED]> writes:
> >> OK, updated patch attached. This has
> >
> >> -E or --default-database=
> >
> > Not sure that "default" databas
Patch applied. Thanks.
---
Dave Page wrote:
> Tom Lane wrote:
> > Dave Page <[EMAIL PROTECTED]> writes:
> >> pg_dumpall -g -- Dump roles and tablespaces per current behaviour
> >> pg_dumpall -gr -- Dump roles only (or user
Patch applied. Thanks.
---
Simon Riggs wrote:
> VERSION 2, with all changed made as requested to date.
>
> As discussed on -hackers, its possible to avoid writing any WAL at all
> for COPY in these circumstances:
>
> htt
Patch applied. Thanks.
---
Simon Riggs wrote:
> On Fri, 2007-01-19 at 11:36 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > >
> > > psql -f copy_nowal_prep.sql postgres
> > > psql -f copy_nowal_test.sql postgre
On Wed, 24 Jan 2007, Tom Lane wrote:
> Not the DB owner. If you are worried about whether to allow use of PLs
> it's almost certainly an installation-wide security concern, so I'd say
> that the privilege has to flow from a superuser.
>
> GRANT CREATE ON LANGUAGE feeding into a flag bit in pltemp
Jeremy Drake <[EMAIL PROTECTED]> writes:
> On Wed, 24 Jan 2007, Tom Lane wrote:
>> that there really needs to be *some* sort of privilege check here.
>> What that is and how to implement it are the hard parts.
> So I guess it depends on what you mean by "DBA". Perhaps the database
> owner? Or so
On Wed, 24 Jan 2007, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > On Wed, 24 Jan 2007, Jeremy Drake wrote:
> >> That would be great, and also it would be great to be able to CREATE
> >> LANGUAGE as a regular user for a trusted pl that is already
> >> compiled/installed.
>
> > Som
On 12/27/2006 01:15 PM, Tom Lane wrote:
I'm not convinced that you're fixing things so much as doing your best
to destroy IEEE-compliant float arithmetic behavior.
I think what we should probably consider is removing CheckFloat4Val
and CheckFloat8Val altogether, and just letting the float arithm
Jeremy Drake <[EMAIL PROTECTED]> writes:
> On Wed, 24 Jan 2007, Jeremy Drake wrote:
>> That would be great, and also it would be great to be able to CREATE
>> LANGUAGE as a regular user for a trusted pl that is already
>> compiled/installed.
> Something like the attached (simple) change to allow C
On Wed, 24 Jan 2007, Jeremy Drake wrote:
> On Wed, 24 Jan 2007, Martijn van Oosterhout wrote:
>
> > Something I've wondered about before is the concept of having installed
> > Modules in the system. Let's say for example that while compiling
> > postgres it compiled the modules in contrib also and
Hi!
The attached patch fixes a bug in plpython.
This bug was found while creating sql from trigger functions
written in plpython and later running the generated sql.
The problem was that boolean was was silently converted to
integer, which is ok for python but fails when the created
sql is used.
Patch applied. Thanks.
---
Magnus Hagander wrote:
> Hiroshi Saito wrote:
> > Hi Magnus-san.
> >
> > I am trying simple construction by operating config.pl.
> > It has changed wonderfully now. however, I do not use ecpg, a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> FAST PostgreSQL wrote:
>> Please find attached the patch with modifications
> are you proposing to implement the other functions in this TODO item
> (pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
> pg_get_tabledef(), pg_get_functiondef() )
FAST PostgreSQL wrote:
Please find attached the patch with modifications
are you proposing to implement the other functions in this TODO item
(pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
pg_get_tabledef(), pg_get_functiondef() ) ?
cheers
andrew
--
25 matches
Mail list logo
