Re: [HACKERS] Feature suggestion: ON CONFLICT DO NOTHING RETURNING which returns existing row data

> On 5 Oct 2016, at 8:11 PM, Pantelis Theodosiou wrote: > > This can be solved by chaining modifying CTEs. > > Something like this (not tested) that can work with multiple rows inserted: Thanks for the suggestion, but it was actually slower than our current implementation, I believe due to

[HACKERS] Feature suggestion: ON CONFLICT DO NOTHING RETURNING which returns existing row data

Hi all We recently moved to using 9.5 and were hoping to use the new upsert functionality, but unfortunately it doesn’t quite do what we need. Our setup is something like this: CREATE TABLE t1 ( id BIGSERIAL NOT NULL PRIMARY KEY, bk1 INT, bk2 UUID — other columns ); CREATE UNIQUE INDEX

Re: [HACKERS] IPv6 link-local addresses and init data type

> On 31 May 2016, at 2:07 AM, Tom Lane wrote: > > The impression I have is that scopes are not very well standardized --- > eg, OS X reports things like "fe80::1%lo0" not just "%0". If we could > get around that problem it would be worth doing. Yeah, we’d have to just store it as a string I th

[HACKERS] IPv6 link-local addresses and init data type

Hi all I just ran into an issue that was originally reported way back in 2007 - https://www.postgresql.org/message-id/flat/0262b803-b664-4ebe-85b4-3c9a40ea6...@mobygames.com Basically the inet data

Re: [HACKERS] Alter or rename enum value

Just stumbled across this thread while looking for something else… > On 28 Mar 2016, at 12:50 AM, Tom Lane wrote: > What you really need is to prevent the new value from being inserted > into any indexes, but checking that directly seems far more difficult, > ugly, and expensive than the above. >

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 4 July 2014 11:37, Tom Lane wrote: > > > Sure it can - it append RETURNING PRIMARY KEY and hand back a ResultSet > > from whatever was returned. It's CURRENTLY doing that, but it's appending > > RETURNING * and leaving it up to the caller of getGeneratedKeys() to work > > out which columns the

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 4 July 2014 00:07, Tom Lane wrote: > TBH, I thought that RETURNING PRIMARY KEY was already fairly iffy > in that the application would have little idea what it was getting back. > IF EXISTS would make it so spongy as to be useless, IMO. > IF EXISTS is pretty pointless - while the behaviour of

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 27 June 2014 06:14, Gavin Flower wrote: > On 27/06/14 00:12, Rushabh Lathia wrote: > >> INSERT INTO dept VALUES (10,'ACCOUNTING','NEW YORK') returning primary >> key, dname; >> >> I think allowing other columns with PRIMARY KEY would be more useful >> syntax. >> Even in later versions if we wa

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

> > Is it going to save enough to justify depending on a syntax that won't > be universal for a long time to come? > Oh, and on the won't-be-universal-for-a-while point - the status quo works fine, it's just less efficient than it should be. Once someone upgrades to 9.5 or whatever, and upgrades t

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 11 June 2014 10:09, Tom Lane wrote: > I'm not even 100% sold that automatically returning the primary key > is going to save any application logic. Could somebody point out > *exactly* where an app is going to save effort with this type of > syntax, compared to requesting the columns it wants

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 10 June 2014 17:49, Hannu Krosing wrote: > RETURNING GENERATED KEYS perhaps, but then how do we determine that? > > What about RETURNING CHANGED FIELDS ? > > Might be quite complicated technically, but this is what is probably > wanted. > Seems to be getting further away from something that

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

A definite +1 on this feature. A while ago I got partway through hacking the hibernate postgres dialect to make it issue a RETURNING clause to spit out the primary key before I realised that the driver was already doing a RETURNING * internally. On 10 June 2014 05:53, Jim Nasby wrote: > I was wo

Re: [HACKERS] jsonb and nested hstore

On 10 February 2014 20:11, Hannu Krosing wrote: > The fastest and lowest parsing cost format for "JSON" is tnetstrings > http://tnetstrings.org/ why not use it as the binary wire format ? > > It would be as binary as it gets and still be generally parse-able by > lots of different platforms, at le

Re: [HACKERS] extension_control_path

On 15 January 2014 03:07, Stephen Frost wrote: > For my 2c, I could absolutely see it as being worthwhile to have an > independent directory to install not-from-package extensions. That > would keep things which are "managed by the package system" and things > which are installed independent sepa

Re: [HACKERS] Proposed feature: Selective Foreign Keys

On 5 Dec 2013, at 03:48, Andrew Dunstan wrote: >>> Well I guess we could say something like: >>> >>>FOREIGN KEY (a-col) WHERE (a-condition) REFERENCES b(b-col) WHERE >>>(b-condition) >>> > > OK, those make sense. I wonder whether this should be done via a USING clause > on the constra

Re: [HACKERS] Proposed feature: Selective Foreign Keys

On 5 Dec 2013, at 06:10, Tom Lane wrote: > Andrew Dunstan writes: Well I guess we could say something like: FOREIGN KEY (a-col) WHERE (a-condition) REFERENCES b(b-col) WHERE (b-condition) > > I like what you have above. Yeah. Given both the apparent ambiguity of the

Re: [HACKERS] Proposed feature: Selective Foreign Keys

On 4 December 2013 01:24, Robert Haas wrote: > Yeah, more or less, but the key is ensuring that it wouldn't let you > create the constraint in the first place if the partial index > specified *didn't* match the WHERE clause. For example, suppose the > partial index says WHERE parent_entity = 'eve

Re: [HACKERS] Proposed feature: Selective Foreign Keys

On 3 Dec 2013, at 12:37, Tom Lane wrote: > Tom Dunstan writes: >> Well, with this patch, under the hood the FK query is doing (in the case of >> RESTRICT): > >> SELECT 1 FROM ONLY "public"."comment" x WHERE (the id) >> OPERATOR(pg_catalog.=)

Re: [HACKERS] Extension Templates S03E11

On 3 December 2013 12:12, Tom Lane wrote: > "Problem"? It's not a bug that you get hstore 1.2 when you dump from 9.2 > and reload into 9.3; that's a feature. You wanted an upgrade, presumably, > or you'd not have been going to 9.3 in the first place. The entire reason > why the extension mechan

Re: [HACKERS] Extension Templates S03E11

On 3 December 2013 02:02, Dimitri Fontaine wrote: > Stephen Frost writes: >> On the other hand, I can appreciate the concern that we don't really >> want a dump/restore to include the extension definition when it's >> already on the filesystem. That said, it amazes me that we don't >> include th

Re: [HACKERS] Proposed feature: Selective Foreign Keys

On 3 Dec 2013, at 03:37, Robert Haas wrote: > I also like this feature. It would be really neat if a FOREIGN KEY > constraint with a WHERE clause could use a *partial* index on the > foreign table provided that the index would be guaranteed to be predOK > for all versions of the foreign key che

Re: [HACKERS] Proposed feature: Selective Foreign Keys

On 3 Dec 2013, at 01:34, Andrew Dunstan wrote: > We wanted to apply FK constraints to a very large table, but grandfather in > certain cases that didn't meet the constraint. That could have been done very > simply using this feature. Yeah, references to old data is the other obvious case for

Re: [HACKERS] Proposed feature: Selective Foreign Keys

Hi Laurenz! On 2 Dec 2013, at 19:27, Albe Laurenz wrote: > What strikes me is that since foreign key constraints are implemented > as triggers in PostgreSQL, this solution would probably not have many > performance benefits over a self-written trigger that implements the > same functionality. Si

[HACKERS] Proposed feature: Selective Foreign Keys

Hi all! The Problem - One case that traditional SQL doesn't handle very well is when you have a child entity which can be attached to a number of different parent entities. Examples might be comments, tags or file attachments - we might have 20 different entities in the system t

[HACKERS] Evaluate arbitrary expression on tuple inside trigger function?

Hi all I'm trying to hack a trigger function to evaluate an expression on the tuple that the trigger has been fired for, kinda like a check constraint. I looked at ExecRelCheck in execMain.c which does more-or-less what I want to do, and I have the parsed node tree all ready to go. The problem tha

Re: [HACKERS] Patch to add support of "IF NOT EXISTS" to others "CREATE" statements

On 13 June 2013 04:30, Peter Eisentraut wrote: > I'm wondering where "IF NOT EXISTS" and "OR REPLACE" will meet. > CREATE OR REPLACE (or ALTER / UPDATE ?) would definitely be useful for enums, where it would be nice if we could teach an ORM to generate DDL based on the current values of the enum

Re: [HACKERS] Configurable location for extension .control files

On 12 June 2013 17:30, Dave Page wrote: > Messing with the path (or the dynamic load path) can cause all sorts > of fun and interesting problems for users, as we found in the early > days with the EDB installers. I realise it doesn't help these users > (who doubtless don't know it exists) but wha

Re: [HACKERS] Configurable location for extension .control files

On 12 June 2013 16:30, Craig Ringer wrote: > None of this is hard if you have clue what you're doing. Rebuild the Pg > gem against the right libpq by fixing your PATH so it finds the right > pg_config, set host=/tmp, or set host=localhost. Any of the three will > work. Unfortunately most of thes

Re: [HACKERS] Configurable location for extension .control files

On 12 June 2013 16:12, Craig Ringer wrote: > Yes, they do - including a horde of deeply confused and frustrated Rails > users struggling to understand why they're getting "no such file or > directory" or "permission denied" messages about Pg's unix socket, > because of course they're linked to Ap

Re: [HACKERS] Configurable location for extension .control files

On 12 June 2013 14:19, Craig Ringer wrote: > Postgres.app is the source of quite a lot of other pain too, though. One > of the bigger problems is that people want/need to link to its libpq > from client drivers like Ruby's Pg gem, but almost inevitably instead > link to libpq from Apple's ancient

Re: [HACKERS] Configurable location for extension .control files

Hi Josh On 11 June 2013 04:37, Josh Berkus wrote: > I don't personally see a reason for plural locations, but it would be > nice if it recursed (that is, looked for .so's in subdirectories). My > reason for this is that I work on applications which have in-house > extensions as well as public o

Re: [HACKERS] Configurable location for extension .control files

On 5 June 2013 05:58, Andres Freund wrote: > Yea, I know of Dimitri's work ;). But I really would like this to work > for C extensions as well. For me personally its no problem at all that > this wouldn't work on conservatively configured machines. Heck, I > *don't* want it to work on production

Re: [HACKERS] [JDBC] JPA + enum == Exception

> -Original Message- > From: pgsql-jdbc-ow...@postgresql.org > [mailto:pgsql-jdbc-ow...@postgresql.org] On Behalf Of Marc G. Fournier > I'm trying to use enum's in a database, but the java guys are telling me that > they are having problems with inserts ... > reading from the database isn

Re: [HACKERS] PostgreSQL extensions packaging

Oops, sent with wrong from header... -- Forwarded message -- From: "Tom Dunstan" <[EMAIL PROTECTED]> To: "Dimitri Fontaine" <[EMAIL PROTECTED]> Date: Wed, 23 Jul 2008 19:40:30 -0400 Subject: Re: [HACKERS] PostgreSQL extensions packaging Hi!

Re: [HACKERS] PostgreSQL extensions packaging

Hi! On Wed, Jul 23, 2008 at 5:08 PM, Dimitri Fontaine <[EMAIL PROTECTED]> wrote: > I promised to have an in-depth look at the archives before to spend time on > my ideas for $subject, but failed to do so. I guess that means you missed both the original discussion at http://archives.postgresql.org

Re: [HACKERS] Crash in pgCrypto?

Coming to this thread a bit late as I've been out of email connectivity for the past week... On Tue, Jun 17, 2008 at 2:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > In any case, trying to define a module as a schema doesn't help at all > to solve the hard problem, which is how to get this stuff to

Re: [HACKERS] [PATCHES] Database owner installable modules patch

On Sat, May 10, 2008 at 11:02 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > Where are we on this? I haven't had time to do any work since the original patch. That patch was fairly basic - it just ran install / uninstall scripts and created catalog entries, and introduced some slightly exotic sy

Re: [HACKERS] Protection from SQL injection

On Tue, Apr 29, 2008 at 12:25 AM, Thomas Mueller <[EMAIL PROTECTED]> wrote: > What do you think about it? Do you think it makes sense to implement > this security feature in PostgreSQL as well? If not why not? Does > PostgreSQL have another solution or plan to solve the SQL injection > problem

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing

On Mon, Apr 28, 2008 at 2:24 PM, Zeugswetter Andreas OSB SD <[EMAIL PROTECTED]> wrote: > I think you are not considering existing btree indexes here > (for the reordering case) ? You're quite right, I had not considered existing indexes. There's no easy way to deal with that other than rebuildin

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing

On Sat, Apr 26, 2008 at 2:51 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > I'm not ... it strikes me that it will add implementation complexity and > runtime overhead for a feature that two days ago we didn't think we > needed at all, and IMHO one we still shouldn't be thinking to expend a > lot of

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing

Oops, sorry for the crossed emails, slight delay in my main being received. On Sat, Apr 26, 2008 at 2:18 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > I think with something like your 16bit/16bit design, and say ten free > codes between each original assignment, it'd be okay to not support the > re

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing

On Sat, Apr 26, 2008 at 2:07 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > > The very first idea that I had was to have an enum value as > > the combination of both an enum id and the ordinal value. > > I seem to remember that we discussed that and rejected it, but I don't > remember the reasoning.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing

On Fri, Apr 25, 2008 at 11:57 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > We already support rewriting tables ... (albeit only one at a time, I > admit. Doing it for more than one can cause deadlocks). > > Still, if the user wants to pay the cost, why should we prohibit it? One scenario I'

Re: [HACKERS] Re: [COMMITTERS] pgsql: Update: < * Allow adding enumerated values to an existing

On Sat, Apr 26, 2008 at 12:10 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote: > Has anyone had a close look at how hard it would be allow just the > "add to the end" capability? If the OIDs haven't wrapped around since the enum was created, it's trivial. If they have, well someone with more OID-fu t

Re: [HACKERS] Lessons from commit fest

On Wed, Apr 16, 2008 at 1:07 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote: > I think pg_indent has to be made a lot more portable and easy to use > before that can happen :-) I've run it once or twice on linux machines, > and it comes out with huge changes compared to what Bruce gets on his >

Re: [HACKERS] Commit fest queue

(I've already said that I think the wiki is a great step forward, FWIW, and I'm not in any way suggesting that we should just drop it and pick my favorite issue tracker or anything. However, for those interested in discussion about theoretical benefits and cons of the different systems...) On Fri,

Re: [HACKERS] Commit fest queue

On Fri, Apr 11, 2008 at 1:32 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote: > > > The apache group seems to say the patches are indeed ignored, rather > > > then just delayed --- for us, every patch does get a reply, however > > > delayed. > > > > > > > Bruce, I think that this comes back to

Re: [HACKERS] Commit fest queue

On Thu, Apr 10, 2008 at 3:41 PM, Gregory Stark <[EMAIL PROTECTED]> wrote: > >> What's wrong with a patch submitter submitting a patch to a tracker, > >> but then emailing the list for actual discussion? > > What's what we have today with the wiki. We don't need any special software > to > do t

Re: [HACKERS] Commit fest queue

On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote: > well what about having the tracker being subscribed to the list and let it > create a bug/patch/ticket id automatically for new mails - that way all > stuff is automatically tracked ? - That way it can be categoriz

Re: [HACKERS] Commit fest queue

On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark <[EMAIL PROTECTED]> wrote: > > The typical way to solve this is to have the tracker send an automatic > > notification email to a list saying "Hey, there's a new ticket at , > > come and check it out". > > Unfortunately that is the typical way to "s

Re: [PATCHES] [HACKERS] Database owner installable modules patch

On Mon, Apr 7, 2008 at 7:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Tom Dunstan" <[EMAIL PROTECTED]> writes: > > OK, I found an example that does NOT fit the "just drop all > > dependencies" scenario, but that I would still like to support

Re: [HACKERS] Database owner installable modules patch

Sorry to keep replying to myself, but part of the point of doing a patch was to force myself (and whoever else is interested to examine stuff that comes up... On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <[EMAIL PROTECTED]> wrote: > None of that suggests that an uninstaller script

Re: [HACKERS] Database owner installable modules patch

On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <[EMAIL PROTECTED]> wrote: > On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark <[EMAIL PROTECTED]> wrote: > > I wonder if there's much of a use case for any statements aside from > CREATE > > statements. If we restri

Re: [HACKERS] Database owner installable modules patch

On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark <[EMAIL PROTECTED]> wrote: > I wonder if there's much of a use case for any statements aside from CREATE > statements. If we restrict it to CREATE statements we could hack things to > create pg_depend entries automatically. In which case we wouldn't

Re: [HACKERS] modules

On Sat, Apr 5, 2008 at 5:11 PM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > It even went so far that you could build the install/deinstall scripts > into the module itself, so all postgres had to do was dlopen() the > module it could access the install script. It fails due to the fact >

Re: [HACKERS] modules

On Sat, Apr 5, 2008 at 12:22 AM, Gregory Stark <[EMAIL PROTECTED]> wrote: > "Aidan Van Dyk" <[EMAIL PROTECTED]> writes: > > > What if you didn't need super-user privileges to load "C" functions, on > > the conditions that: > > 1) There is no / in the obj_file filename (or some other "sanitizing"

Re: [HACKERS] modules

On Fri, Apr 4, 2008 at 10:48 AM, Jeremy Drake <[EMAIL PROTECTED]> wrote: > My opinion is, it doesn't matter what you call the modules/contrib stuff > if I can't use it, and I can't use it if it is not loaded in my > database, and I can't load it without superuser privileges. Right. Which is w

Re: [HACKERS] modules

On Thu, Apr 3, 2008 at 10:36 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > No. I don't want to deprecate it, I want to get rid of it, lock, stock and > barrel. If you think that we need more than renaming then we can discuss it, > but I don't want a long death, I want one that is certain and swi

Re: [HACKERS] modules

On Thu, Apr 3, 2008 at 9:17 PM, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > > It's hard to see ISPs who won't install contrib from installing > > ${random module} from the big bad internet as has been discussed in > > this thread, but who knows? > > Sure it is. The very word contrib brings abo

Re: [HACKERS] modules

On Thu, Apr 3, 2008 at 8:25 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > If this were at all true we would not not have seen the complaints from > people along the lines of "My ISP won't install contrib". But we have, and > quite a number of times. We have concrete evidence that calling it con

Re: [HACKERS] modules

I had some thoughts about similar issues when looking at what it would take to make pl/java yum-installable. The end goal was to be able to say e.g. yum install pljava; echo "create language pljava;" | psql mydb. Currently there's a non-trivial install process involving running an sql script and ja

Re: [HACKERS] UUID data format 4x-4x-4x-4x-4x-4x-4x-4x

On Fri, Feb 29, 2008 at 9:26 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > Andrew Sullivan <[EMAIL PROTECTED]> writes: > > "Be conservative in what you send, and liberal in what you accept." > > Yeah, I was about to quote that same maxim myself. I don't have a big > problem with allowing uuid_in to

Re: [HACKERS] An idea for parallelizing COPY within one backend

On Wed, Feb 27, 2008 at 9:26 PM, Florian G. Pflug <[EMAIL PROTECTED]> wrote: > I was thinking more along the line of letting a datatype specify a > function "void* ioprepare(typmod)" which returns some opaque object > specifying all that the input and output function needs to know. > We could t

Re: [HACKERS] pg_dump additional options for performance

On Tue, Feb 26, 2008 at 5:35 PM, Simon Riggs <[EMAIL PROTECTED]> wrote: > On Tue, 2008-02-26 at 12:46 +0100, Dimitri Fontaine wrote: > > As a user I'd really prefer all of this to be much more transparent, and > could > > well imagine the -Fc format to be some kind of TOC + zip of table data +

Re: [HACKERS] pg_dump additional options for performance

On Sun, Feb 24, 2008 at 6:52 PM, Jochem van Dieten <[EMAIL PROTECTED]> wrote: > Or we could have a switch that specifies a directory and have pg_dump > split the dump not just in pre-schema, data and post-schema, but also > split the data in a file for each table. That would greatly facilitate >

Re: [HACKERS] unclear enum error messages

On Nov 28, 2007 11:01 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > > What is an actual enum type? And how should a user react if he got this > > message? I would ask, "why not?". > > Yeah, I would too, but without a concrete example to look at it's hard > to say if the situation could be improved.

Re: [HACKERS] [hibernate-team] PostgreSQLDialect

On Nov 12, 2007 4:08 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > What should the driver report then ? I believe the backend code considers 8 > > to be the major version, and 0123 to be the minor versions ? > > No, 8.1 is the major version. In 8.2.5, 8.2 is the major, 5 is the > minor version

Re: [HACKERS] [hibernate-team] PostgreSQLDialect

On Nov 12, 2007 2:13 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > Oh, that's nice. Unfortunately, though. it only seems to support major > > version number differentiation as an int. Apparently the idea that you > > might have a version number like 8.3 didn't occur to whoever wrote it, > > alt

Re: [HACKERS] [hibernate-team] PostgreSQLDialect

On Nov 12, 2007 1:08 PM, Simon Riggs <[EMAIL PROTECTED]> wrote: > If we do this, then it looks like we can hack this file also > http://anonsvn.jboss.org/repos/hibernate/core/trunk/core/src/main/java/org/hibernate/dialect/DialectFactory.java Oh, that's nice. Unfortunately, though. it only seems t

Re: [HACKERS] [hibernate-team] PostgreSQLDialect

> All of this should work for functions, but operators are a whole > different story. I strongly suspect that someone is not going to be > able to use e.g. @@ in a HQL query. Are there ways to do tsearch type > queries just using functions and more standard operators? Of course, if someone's using

Re: [HACKERS] [hibernate-team] PostgreSQLDialect

[oops, sent with non-subscribed from: address first time] On Nov 12, 2007 10:55 AM, Simon Riggs <[EMAIL PROTECTED]> wrote: > I've posted files to pgsql-patches, as well as to Diego directly. I dropped them into a Hibernate 3.2.5.ga source tree and ran the hibernate tests with the 8.3 dialect agai

Re: [HACKERS] [hibernate-team] PostgreSQLDialect

On Nov 12, 2007 10:55 AM, Simon Riggs <[EMAIL PROTECTED]> wrote: > I've posted files to pgsql-patches, as well as to Diego directly. I dropped them into a Hibernate 3.2.5.ga source tree and ran the hibernate tests with the 8.3 dialect against pgsql HEAD and got a few errors. Diego, I assume that t

Re: [HACKERS] [hibernate-team] PostgreSQLDialect

> Hi, I've never used Hibernate but it seems to be that table of > functions could be generated automatically. That's the obvious solution. It would be nice if the dialect could query the database itself to get a list of functions, since there will be different sets of functions for different serv

Re: [HACKERS] "anyelement2" pseudotype

Tom Lane wrote: I realized that I can probably fix ATAddForeignKeyConstraint to do the right thing by having it pass the two actual column types to can_coerce_type, thus allowing check_generic_type_consistency to kick in and detect the problem. Yeah, I came to the same conclusion. No amount of

Re: [HACKERS] "anyelement2" pseudotype

Tom Lane wrote: So it seems neither can_coerce_type() nor find_coercion_pathway() are really particularly well thought out in terms of what they test or don't test. I'm not very sure what a good refactoring would look like, but I am sure that I don't want all their call sites having to individua

Re: [HACKERS] "anyelement2" pseudotype

Tom Lane wrote: Actually ... now that I re-read that remark, I think you may have done the wrong things with ANYENUM. I think that ANYENUM may in fact be closer to ANYARRAY than it is to ANYELEMENT, because ANYELEMENT pretty nearly means "anything at all" whereas ANYARRAY identifies a subset of

Re: [HACKERS] "anyelement2" pseudotype

Tom Dunstan wrote: Tom Lane wrote: As for actually adding it, grep for all references to ANYELEMENT and add code accordingly; shouldn't be that hard. Note you'd need to add an anyarray2 at the same time for things to keep working sanely. The enum patch [1] does exactly this with

Re: [HACKERS] "anyelement2" pseudotype

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Tom Lane wrote: ANYENUM? What's the use-case for that? Well ... *somebody* suggested it here ... http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php Well, in that usage (ie, for enum I/O functions) it's not actually

Re: [HACKERS] "anyelement2" pseudotype

Tom Lane wrote: As for actually adding it, grep for all references to ANYELEMENT and add code accordingly; shouldn't be that hard. Note you'd need to add an anyarray2 at the same time for things to keep working sanely. The enum patch [1] does exactly this with an ANYENUM pseudo-type. It shoul

Re: [HACKERS] effective_cache_size vs units

Tom Lane wrote: (Hmm, I wonder what Tom Dunstan's enum patch does about case sensitivity...) Currently enum labels are case sensitive. I was a bit ambivalent about it... case insensitivity can lead to less surprises in some cases, but many programming languages that have enums are case sensi

Re: [HACKERS] [PATCHES] Enums patch v2

Peter Eisentraut wrote: An objection to enums on the ground that foreign keys can accomplish the same thing could be extended to object to any data type with a finite domain. Exactly. The extreme case is the boolean type, which could easily be represented by a two-value enum. Or, if you were

Re: [HACKERS] [PATCHES] Enums patch v2

Alvaro Herrera wrote: I don't, because there are always those that are knowledgeable enough to know how to reduce space lost to padding. So it would be nice to have 2-byte enums on-disk, and resolve them based on the column's typid. But then, I'm not familiar with the patch at all so I'm not su

Re: [HACKERS] Custom Data Type Question

Hi Greg Greg Mitchell wrote: I'm trying to create a custom data type similar to an enumeration type. However, I'd like the mapping of the int<->string to be dynamic instead of hard coded. I'd like to have a table that contains this mapping that can be appended to. Creating this type is not ve

Re: [HACKERS] Backup and restore through JDBC

Markus Schaber wrote: Marlon Petry wrote: But I would need to have installed pg_dump and pg_restore in machine client? Without having installed pg_dump and pg_restore,how I could make pg_dump and pg_restore should be runnable (possible with a small shell / bash wrapper script) without any "ins

Re: [HACKERS] 8.3 Development Cycle

Tom Lane wrote: Tom Dunstan <[EMAIL PROTECTED]> writes: Joshua's original mail suggested that only certain features would go in. Is that still on the cards, or will other features be considered if they're ready? You'll note that Dave's mail said no such thing.

Re: [HACKERS] 8.3 Development Cycle

Josh Berkus wrote: I'm obviously thinking of enums which was ready (for review at least) a few weeks ago, but has probably bitrotted slightly since then given the number of patches that have landed in the tree. I intended to brush it up as soon as the 8.3 tree was open and resubmit it. Will that

Re: [HACKERS] 8.3 Development Cycle

Dave Page wrote: This will obviously be a short development cycle which will allow us to get some of the features that just missed 8.2 out of the door, as well as giving us the opportunity to try releasing before the summer (for those in the northern hemisphere) rather than after. Joshua's orig

Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)

[EMAIL PROTECTED] wrote: Really this whole debate only reinforces the point that there isn't a single way of doing UUID generation. There are multiple libraries out there each with pros and cons. It makes more sense to have multiple pgfoundry UUID generating modules. Exactly. If I lead you to t

Re: [HACKERS] Opinion wanted on UUID/GUID datatype output formats.

devdb=# select * from tbluuid; pk| --+ 6b13c5a1afb4dcf5ce8f8b4656b6c93c | 01e40a79b55b6e226bffb577e960453d | (2 rows) The UUID standards define a single perfectly clear format, and the one you show is not it. I was wondering if

Re: [HACKERS] An Idea for OID conflicts

Whoops, I hadn't read this far when I sent the last message on the other thread. Gevik Babakhani wrote: 3. Make a small utility that goes through a patch, finds the new OIDs and changes them back to a value specified by the committer(s). This is effectively what I ended up suggesting in the

Re: [HACKERS] OID conflicts

Andrew Dunstan wrote: You misunderstood me. I meant he wanted to make use of such a facility, not that he wanted to build it. Yeah, I had enough things on my plate just getting enums to work :) By all means float ideas on this - the problem seems to me to be ensuring that reservations are tim

Re: [HACKERS] An Idea for OID conflicts

Tom Lane wrote: The scary thing about a script is the assumption that it will make all and only the changes needed. Four-digit magic numbers are not that uncommon in C code. I think it might be safer if we made the arbitrary OID range for an uncommitted patch be large, say eight digits (maybe "

Re: [HACKERS] An Idea for OID conflicts

Gregory Stark wrote: Those types, functions and operators that aren't used by system tables could be created by a simple SQL script instead. It's a hell of a lot easier to write a CREATE OPERATOR CLASS call than to get all the OIDs in in four different include files to line up properly. No kidd

Re: [HACKERS] OID conflicts

Martijn van Oosterhout wrote: Seems awfully complicated. The numbers don't mean anything, they don't have to be contiguous. If you want to reduce the chance of conflict, find a nice big block in unused_oids, add a random number between 0 and 100 and use that. Or squeeze yourself into a block tha

Re: [HACKERS] An Idea for OID conflicts

Whoops, I hadn't read this far when I sent the last message on the other thread. Gevik Babakhani wrote: 3. Make a small utility that goes through a patch, finds the new OIDs and changes them back to a value specified by the committer(s). This is effectively what I ended up suggesting in the a

Re: [HACKERS] Mid cycle release?

Joshua D. Drake wrote: O.k. that was negative, sorry. Frankly I think that turning autovacuum on by default pretty much equates to, "I am lazy, and I don't want to actually evaluate my needs. Lets just go with MS Access" Please ignore my negativity today. I apologize. I do not want autovacuum

Re: [HACKERS] Mid cycle release?

Joshua D. Drake wrote: No one would expect Oracle to install Oracle and walk away. We are not MySQL, nor MS Access. And thank goodness for that! Tom ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate

Re: [HACKERS] Getting a move on for 8.2 beta

Jeremy Drake wrote: On Wed, 13 Sep 2006, Tom Dunstan wrote: I was under the impression that most VM products are x86 centric, which wouldn't lead to huge amounts of diversity in the buildfarm results. At least, not as far as architecture goes. I have played with QEmu (www.qemu.org) whi

Re: [HACKERS] Getting a move on for 8.2 beta

Jim Nasby wrote: That's something I'd be willing to do. And for many people that aren't committers but are still trusted in the community, we could probably bypass the checking. That's a worthwhile point. How many patches come from the general community vs out of the blue? Patches from regula

Re: [HACKERS] Getting a move on for 8.2 beta

Jim C. Nasby wrote: There's been talk in the past of having some kind of system that automatically attempts to build things that are in the patch queue, both as an initial sanity-check and as a means to detect when something bit-rots... perhaps it's becoming worthwhile to set that up. After wri

  1   2   >