On Sun, 26 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 04:50:41PM -0500, Rod Taylor wrote:
> On Sat, Feb 25, 2006 at 02:01:00PM -0800, Stephan Szabo wrote:
> | > On Sat, 25 Feb 2006, Clark C. Evans wrote:
> | > >
> | > > CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
> | > >
On Sun, 26 Feb 2006, Clark C. Evans wrote:
> Stephen,
>
> So, a quick re-cap of the questions/concerns I had:
>
> * Making the default constraint names include the table
>
> -> This was implemented in 8.x, thank you!
>
> * Forbidding the creation of a foreign key constraint where
> th
Stephen,
So, a quick re-cap of the questions/concerns I had:
* Making the default constraint names include the table
-> This was implemented in 8.x, thank you!
* Forbidding the creation of a foreign key constraint where
the column list for the referenced table doesn't *exactly*
On Sat, Feb 25, 2006 at 04:50:41PM -0500, Rod Taylor wrote:
| Can out point it out in the below psql output?
|
| k=# CREATE TABLE x (y text, z text, PRIMARY KEY(y,z));
| NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "x_pkey"
| for table "x"
| CREATE TABLE
| k=# CREATE TABL
In my opinion we should cater for such a situation, and two possible
solutions come to my mind for this:
I've done exactly this before, and had to use single user mode to
recover. Annoying.
1. Place a restriction that there should be more than one superuser
before you can issue a "NOCREATEU
Neil Conway wrote:
> 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 th
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
On Sat, Feb 25, 2006 at 01:21:34PM -0700, I wrote:
> From what I have seen of zope's restricted python, it does, or can, force its
> restrictions by checking bytecode. I imagine a simple PL sitting on top of the
> untrusted varient that merely implements a custom validator that checks the
> bytecod
On Sat, Feb 25, 2006 at 06:36:19PM -0300, Alvaro Herrera wrote:
> I'm not sure it's an issue now that we have pg_pltemplate, but in older
> versions it's possible to create a language without setting a validator.
> This would make the validator an unsuitable place for checking the
> restrictions.
Guys,
So, based on this discussion, I'd like to consider taking a second stab at
newsysviews:
1) Implement SQL03 changes into the information_schema, using some of the
code from newsysviews;
2) Modify the newsysviews to be extensions of the information_schema views:
e.g. information_sc
On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
> Bruno,
>
> > This has been discussed previously in a couple of threads. I believe the
> > desire is to make it work as specified in SQL-2003, but I do not remember
> > whether or not anyone volunteered to do the work to make it happen.
On Sat, 25 Feb 2006, Stephan Szabo wrote:
>
> On Sat, 25 Feb 2006, Clark C. Evans wrote:
>
> > On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
> > | > > * for foreign-key and check constraints, the default names
> > | > > are $1, $2, etc.; it would be great if they were "upgra
On Sat, 25 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
> | > > * for foreign-key and check constraints, the default names
> | > > are $1, $2, etc.; it would be great if they were "upgraded"
> | > > to use the default names given by pr
On Sat, 2006-02-25 at 16:35 -0500, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
> | > > * for foreign-key and check constraints, the default names
> | > > are $1, $2, etc.; it would be great if they were "upgraded"
> | > > to use the default names
On Sat, Feb 25, 2006 at 12:51:51PM -0800, Stephan Szabo wrote:
| > > * for foreign-key and check constraints, the default names
| > > are $1, $2, etc.; it would be great if they were "upgraded"
| > > to use the default names given by primary and unique key
| > > constraints: table_uk
James William Pye wrote:
> On Sat, Feb 25, 2006 at 10:09:52AM +0100, Tino Wildenhain wrote:
> > And with even more love the restricted python from zope could
> > be ported so there could be a pl/python again :-)
> >
> > Ok, just haluzinating ;)
>
> Not necessarily. ;)
>
> From what I have seen o
On Sat, 25 Feb 2006, Stephan Szabo wrote:
>
> On Sat, 25 Feb 2006, Clark C. Evans wrote:
>
> > On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
> > | > This has been discussed previously in a couple of threads. I believe the
> > | > desire is to make it work as specified in SQL-2003,
On Sat, 25 Feb 2006, Clark C. Evans wrote:
> On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
> | > This has been discussed previously in a couple of threads. I believe the
> | > desire is to make it work as specified in SQL-2003, but I do not remember
> | > whether or not anyone volu
On Sat, Feb 25, 2006 at 10:09:52AM +0100, Tino Wildenhain wrote:
> And with even more love the restricted python from zope could
> be ported so there could be a pl/python again :-)
>
> Ok, just haluzinating ;)
Not necessarily. ;)
>From what I have seen of zope's restricted python, it does, or ca
On Sat, Feb 25, 2006 at 11:51:55AM -0800, Josh Berkus wrote:
| > This has been discussed previously in a couple of threads. I believe the
| > desire is to make it work as specified in SQL-2003, but I do not remember
| > whether or not anyone volunteered to do the work to make it happen.
|
| I beli
Bruno,
> This has been discussed previously in a couple of threads. I believe the
> desire is to make it work as specified in SQL-2003, but I do not remember
> whether or not anyone volunteered to do the work to make it happen.
I believe that the newsysviews follow the SQL03 permissions structure
On Fri, Feb 24, 2006 at 19:40:33 -0500,
"Clark C. Evans" <[EMAIL PROTECTED]> wrote:
>
> While the textual description of this view "Identify domain constraints
> in this catalog accessable to a given user." has not changed between
> SQL-1992 and SQL-2003, the actual critera specified is quite di
On 2/24/06, Rafael Martinez Guerrero <[EMAIL PROTECTED]> wrote:
> Hello
>
> In version 7.4.x, the function textToQualifiedNameList was defined with
> two parameters.
>
> Some months ago, the second parameter was removed [1] so I had to modify
> my program to work after this change. Now with 8.0.7,
Martin Pitt <[EMAIL PROTECTED]> writes:
> Martin Pitt [2006-02-19 14:39 +0100]:
>> Since this changes the behaviour of pg_restore, this should probably
>> become an option, e. g. -D / --ignore-existing-table-data. I'll do
>> this if you agree to the principle of the current patch.
> I improved the
Martin Pitt wrote:
> Hi again,
>
> Martin Pitt [2006-02-19 14:39 +0100]:
> > Since this changes the behaviour of pg_restore, this should probably
> > become an option, e. g. -D / --ignore-existing-table-data. I'll do
> > this if you agree to the principle of the current patch.
>
> I improved the
OK.
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Fri, Feb 24, 2006 at 10:15:39PM -0500, Bruce Momjian wrote:
> >
> > Aren't they in the 8.2 hold queue that I have not processed yet:
> >
> > ht
Thomas Hallgren wrote:
Peter Eisentraut wrote:
Thomas Hallgren wrote:
# Default shlib naming convention used by the majority of platforms
shlib=
lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
shlib_major= lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
shlib_ba
Thomas Hallgren wrote:
> In that case, I'd appreciate some advice on how to use the pgxs package
> to compile a 'plug-in'. Looks to me it's only designed to compile
> 'shared libraries'.
You can just use the Makefile.shlib rules normally and then rename the
file during installation. PL/pgSQL d
On Fri, Feb 24, 2006 at 10:15:39PM -0500, Bruce Momjian wrote:
>
> Aren't they in the 8.2 hold queue that I have not processed yet:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Hmm yeah. Didn't know about that page.
The first is ok but the second no longer applies cleanly to H
Peter Eisentraut wrote:
Thomas Hallgren wrote:
# Default shlib naming convention used by the majority of platforms
shlib =
lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
shlib_major = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
shlib_bare= lib$(NAME)$(DLSUFF
Thomas Hallgren wrote:
> # Default shlib naming convention used by the majority of platforms
> shlib =
> lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
> shlib_major = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
> shlib_bare = lib$(NAME)$(DLSUFFIX)
>
> and sure e
Hi again,
Martin Pitt [2006-02-19 14:39 +0100]:
> Since this changes the behaviour of pg_restore, this should probably
> become an option, e. g. -D / --ignore-existing-table-data. I'll do
> this if you agree to the principle of the current patch.
I improved the patch now to only ignore TABLE DATA
I have a PL/Java bug entry from Peter E. that reads "It is customary in PostgreSQL land and
elsewhere, that dynamically loadable modules do not have a lib prefix (compare plpgsql.so,
pltcl.so, etc.). So I suggest that the shared object installed by PL/Java also be called
exactly pljava.so.".
Ühel kenal päeval, L, 2006-02-25 kell 10:09, kirjutas Tino Wildenhain:
> James Robinson schrieb:
> > I see neilc has hacked on it very recently to reduce memory leaks. I
> > take that as both good and bad signs.
> >
> > We're a [ small ] python shop, and would be most interested in being
> > abl
James Robinson schrieb:
> I see neilc has hacked on it very recently to reduce memory leaks. I
> take that as both good and bad signs.
>
> We're a [ small ] python shop, and would be most interested in being
> able to simplify our life through doing some things in plpython instead
> of pl/pgsql
35 matches
Mail list logo
