Am 13.04.2012 20:35, schrieb Scott Marlowe:
On Thu, Apr 12, 2012 at 2:16 AM, Thomas Guettler wrote:
Hi,
I think it would be very good, if postgresql reports which column is too
small:
Value to long for type character varying(1024) (message translated from
german to english)
Is there a rea
Thomas Guettler wrote:
> Am 13.04.2012 20:35, schrieb Scott Marlowe:
>> On Thu, Apr 12, 2012 at 2:16 AM, Thomas Guettler wrote:
>>> Hi,
>>>
>>> I think it would be very good, if postgresql reports which column is too
>>> small:
>>>
>>>Value to long for type character varying(1024) (message t
Le dimanche 15 avril 2012 à 15:43 +0200, Tomas Vondra a écrit :
> But if you really need to write the data to a file, you may look at this
> contrib module (called "extension" since 9.1)
>
>http://www.postgresql.org/docs/9.1/interactive/adminpack.html
>
> You may either use that directly or
I have run into trouble with the following bug;
http://postgresql.1045698.n5.nabble.com/BUG-6204-Using-plperl-functions-generate-crash-td4802111.html#a5629612
which was logged first back in September last year.
I can not find details of when [or if] this bug has been fixed [or accepted
as a bug e
Hi,
There is a feature that I have used in SQL Server which I find really
useful for debugging (without using a debugger!!).
It is this I can write multiple "select * from some_table" statements
throughout my stored procedure (here read "pgsql function") and the
individual result sets get "ret
Does anyone know of utilities that will enable importing oracle data
pump files (produced via expdp) into postgresql?
Note that I do not have an installation of Oracle, only the binary
output file produced.
--
Jason Armstrong
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
Hello
2012/4/16 Liam Caffrey :
> Hi,
>
> There is a feature that I have used in SQL Server which I find really useful
> for debugging (without using a debugger!!).
> It is this I can write multiple "select * from some_table" statements
> throughout my stored procedure (here read "pgsql functio
Hi folks,
I'm a happy creator/user of extensions (e.g. my postgresql_debversion
extension). But I'm wondering if they can be used for more than just
simple types:
- can an extension depend upon another extension? This would probably
be implicit based upon the use of an object which belonged t
On Mon, Apr 16, 2012 at 10:05 AM, Roger Leigh wrote:
> Hi folks,
>
> I'm a happy creator/user of extensions (e.g. my postgresql_debversion
> extension). But I'm wondering if they can be used for more than just
> simple types:
>
> - can an extension depend upon another extension? This would proba
On 16 April 2012 09:24, Liam Caffrey wrote:
> Hi,
>
> There is a feature that I have used in SQL Server which I find really useful
> for debugging (without using a debugger!!).
> It is this I can write multiple "select * from some_table" statements
> throughout my stored procedure (here read "
On Mon, Apr 16, 2012 at 10:22:19AM -0500, Merlin Moncure wrote:
> On Mon, Apr 16, 2012 at 10:05 AM, Roger Leigh wrote:
> > The reason for the above is that I'd very much like to be able to
> > version my entire application's schema using the extension mechanism
> > (or something based upon the ide
On Mon, Apr 16, 2012 at 2:24 AM, Liam Caffrey wrote:
> Hi,
>
> There is a feature that I have used in SQL Server which I find really useful
> for debugging (without using a debugger!!).
> It is this I can write multiple "select * from some_table" statements
> throughout my stored procedure (he
On Sat, Apr 14, 2012 at 6:25 AM, Zhidong She wrote:
> thanks, tuning standard_confirming_strings to off make our legacy
> software smoothly upgrade to 9.1.3.
>
Turning to OFF should be good.
> is there any bad effect if we just sets this params off and not modify
> our leacy code to standard E
On Mon, 2012-04-16 at 16:46 +0100, Roger Leigh wrote:
> On Mon, Apr 16, 2012 at 10:22:19AM -0500, Merlin Moncure wrote:
> > On Mon, Apr 16, 2012 at 10:05 AM, Roger Leigh wrote:
> > > The reason for the above is that I'd very much like to be able to
> > > version my entire application's schema usin
On Mon, 2012-04-16 at 21:16 +0200, Guillaume Lelarge wrote:
> On Mon, 2012-04-16 at 16:46 +0100, Roger Leigh wrote:
> > On Mon, Apr 16, 2012 at 10:22:19AM -0500, Merlin Moncure wrote:
> > > On Mon, Apr 16, 2012 at 10:05 AM, Roger Leigh
> > > wrote:
> > > > The reason for the above is that I'd ver
On Mon, Apr 16, 2012 at 2:20 PM, Guillaume Lelarge
wrote:
>> > Every project I've worked on which uses PostgreSQL has independently
>> > implemented its own set of installation and upgrade scripts, which
>> > has typically included some form of table for storing the current
>> > schema version and
Code that works on Pg8.3 raises an error on Pg9.1, is this a bug?
PostgreSQL 8.3.7 on x86_64-unknown-linux-gnu, compiled by GCC
gcc-4.3.real (Debian 4.3.2-1.1) 4.3.2
select pg_try_advisory_lock(123);
pg_try_advisory_lock
--
t
(1 row)
postgres=# begin transaction;
BEGIN
p
17 matches
Mail list logo
