Oleksiy Shchukin wrote:
The following bug has been logged online:
Bug reference: 4599
Logged by: Oleksiy Shchukin
Email address: oleksiy.shchu...@globallogic.com
PostgreSQL version: 8.3.5
Operating system: all
Description:bugfix for contrib/dblink module
[snip]
d
Meredith L. Patterson wrote:
Magnus Hagander wrote:
this has implications for storing passwords as MD5 hashes. My
That would be the only system use of MD5. What implications are those?
We might want to consider using a safer hash for the password storage at
some point, but from what I ga
Joshua Tolley wrote:
On Sat, Jul 11, 2009 at 02:12:22AM +0100, Richard Neill wrote:
Thanks for your reply. Sadly, I haven't the time (or expertise) to write
this myself. However, the feature would be really useful to have. I'd
certainly be willing to make a £200 payment or donation in return.
Tatsuhito Kasahara wrote:
> dblink generates orphaned connections when we failed on performing dblink()
> function.
> # But it occurs only when dblink('conn_str', 'sql', true). See following
> examples.
> I think that the dblink should not ereport() before PQfinish(conn) in
> dblink_record_inter
On 02/01/2010 08:06 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Fujii Masao wrote:
>>> In HEAD, psql using conninfo fails in connecting to the server as follows.
>>>
>>> $ bin/psql "host=localhost"
>>> psql: FATAL: database "host=localhost" does not exist
>>>
>>> This is because the recen
On 02/01/2010 08:06 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Fujii Masao wrote:
>>> In HEAD, psql using conninfo fails in connecting to the server as follows.
>>>
>>> $ bin/psql "host=localhost"
>>> psql: FATAL: database "host=localhost" does not exist
>>>
>>> This is because the recen
On 02/02/2010 05:46 PM, Fujii Masao wrote:
> On Wed, Feb 3, 2010 at 10:05 AM, Joe Conway wrote:
>> Objections?
>
> I think that PQconnectdbParams() rather than psql should handle the
> dbname containing "=". Otherwise whenever we use PQconnectdbParams(),
> we woul
On 02/02/2010 05:59 PM, Tom Lane wrote:
> This seems bogus on a couple of levels. First off, I thought the idea
> was to get away from using PQsetdbLogin at all. If we go down this path
> we'll never be rid of it. Second, to preserve backwards compatibility
> we will have to duplicate this same
On 02/02/2010 06:10 PM, Tom Lane wrote:
> Since we haven't yet released PQconnectdbParams, it's not too late
> to twiddle its API. What I'm thinking about is an additional
> boolean parameter "expand_dbname", which only if true would enable
> treating an equal-sign-containing dbname like a conninf
On 02/02/2010 06:40 PM, Tom Lane wrote:
> The difference with PQconnectdbParams is that the dbname might not be
> the first thing in the parameter array. I think that a straightforward
> implementation would have the effect of the expanded dbname overriding
> parameters given before it, but not th
On 02/02/2010 10:08 PM, Tom Lane wrote:
> Joe Conway writes:
>> Are there any of the psql parameters that we do not want to allow to be
>> overridden by the conninfo string?
>
> Actually, now that I think about it, psql shouldn't be setting
> application_name
On 02/02/2010 10:23 PM, Tom Lane wrote:
> Joe Conway writes:
>> Should I also be looking to replace all (or most) other instances of
>> PQsetdbLogin()?
>
> I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if
> the others are worth troubling over
On 02/04/2010 01:23 AM, Fujii Masao wrote:
> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>> bin/scripts (createdb, vacuumdb, etc). I still need to adjust the docs,
>> but other than that any
On 02/04/2010 08:31 AM, Joe Conway wrote:
> On 02/04/2010 01:23 AM, Fujii Masao wrote:
>> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>>> bin/scripts (createdb, vacuumdb, etc). I still need to adj
On 02/04/2010 09:37 AM, Joe Conway wrote:
> On 02/04/2010 08:31 AM, Joe Conway wrote:
>> On 02/04/2010 01:23 AM, Fujii Masao wrote:
>>> On Thu, Feb 4, 2010 at 1:26 PM, Joe Conway wrote:
>>>> OK, this one includes pg_dump(all)/pg_restore and common.c from
>>>
On 02/24/2010 08:43 AM, Lou Picciano wrote:
> Tom -
>
> Didn't realize I was arm waving - was I? (Sometimes email falls well
> short...)
>
> We've managed a build of PostgreSQL 9.0-alpha4 - nice! However, the #
> make install command apparently(?) hiccups
> on a dependency on Jade (we ain't u
> > Short Description
> > Can't insert a value of 0 (zero) into a Bytea type.
> >
> > Long Description
> > It does not zeem possible to insert a value of zero (0) into a bytea
type. A
> > lso, using '\134' (the octal code for a backslash) causes byteain() to
genera
> > te an error message.
> >
>
[EMAIL PROTECTED] wrote:
> Eric Lu ([EMAIL PROTECTED]) reports a bug with a severity of 4
> The lower the number the more severe it is.
>
> Short Description
> bytea data type problem/bug
>
> Long Description
> Hi,
>
> It happens when I was trying to test the avalaibility of the new binary data
Christopher Browne wrote:
The following bug has been logged online:
If I try to build dblink when PG is configured "--with-openssl", the build
of the contrib module dblink breaks as follows:
If I add, to the GCC command line, requests for libssl and libcrypto...
-lssl -lcrypto
e.g. - comm
Tom Lane wrote:
"Vitali Stupin" <[EMAIL PROTECTED]> writes:
The error "invalid memory alloc request size 4294967293" apears when
selecting array of empty arrays:
select ARRAY['{}'::text[],'{}'::text[]];
I can get a core dump off it too, sometimes. The problem is in
ExecEvalArray, which compu
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Sorry for the slow response -- I'm at the airport just heading home from
a marathon 30 day business trip.
Yow. Hope you get some time off...
Yeah, I just took a week. Next week I'm back to work and the week after
Tom Lane wrote:
"Sokolov Yura" <[EMAIL PROTECTED]> writes:
create or replace function add_group(grp anyarray, ad anyelement, size int4)
returns anyarray
language plpgsql
...
create aggregate build_group(anyelement, int4) (
SFUNC= add_group,
STYPE = anyarray
);
ERROR: argument declared
Dave Page wrote:
On Tue, Mar 18, 2008 at 12:47 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
Mike Leahy wrote:
> Is this actually a bug, or is there a specific reason that the pgxs
> files omitted in the windows installer? I noticed the 8.3.1 installer
> has been posted (as the updates had a
Magnus Hagander wrote:
In general, mingw built modules should load just fine in msvc built
postgres. AFAIK, that's how PostGIS does it for 8.3 (though I know Mark
is working on getting MSVC build support for them). Debugging may be a
bit harder (since they use different kinds of debug symbols - p
Magnus Hagander wrote:
Could this be somethingl ike missing PGDLLIMPORT specifications in your
addon module or something like that? Try checking the names of the
functions that are actually exported using "depends" or a similar tool.
Ah, that sounds likely, since I have never had to worry abou
Tom Lane wrote:
"Henry Combrinck" <[EMAIL PROTECTED]> writes:
Description:perform dblink() in begin/exception returns wrong
SQLSTATE code
The code returned is always 42601 (syntax_error) irrespective of the actual
error (eg, unique_violation).
Yeah, the dblink code should probably t
grant wrote:
> You could fake some of this (select only) by using the dblink stuff in
> contrib. You could link back to yourself and make it work. Maybe if
> you REALLY need it, you could modify dblink to allow updates as well as
> selects. If you really need it that bad, you have the sourc
[EMAIL PROTECTED] wrote:
> David Clark ([EMAIL PROTECTED]) reports a bug with a severity
> Table 3-7 SQL Literal escaped octets shows the input escape
> representation for a single quote as '\\'' , but the third paragraph
> below table 3-8 SQL Output Escaped Octets says that the single quote
Anders Hammarquist wrote:
>>[EMAIL PROTECTED] writes:
>>
>>>If a byte string that is not valid unicode is inserted into a bytea
>>>column, analyze will fail unless the data was tagged as bytea in the
>>>insert.
>>
>>Your example produces no failure for me. You'd better be more specific
>>about wh
Tom Lane wrote:
> Ah. So the issue is that ANALYZE tries to do textin(byteaout(...))
> in order to produce a textual representation of the most common value
> in the BYTEA column, and apparently textin feels that the string
> generated by byteaout is not legal text. While Joe says that the
> pro
Bruce Momjian wrote:
> Does this mean we don't have to esacpe >0x7f when inputting bytea
> anymore?
I seem to remember that bytea data was run through the multibute code
for some reason, and I don't recall seeing that changed. ISTM that we
shouldn't force bytea thought multibyte functions at al
Joe Conway wrote:
> Bruce Momjian wrote:
>
>> Does this mean we don't have to esacpe >0x7f when inputting bytea
>> anymore?
>
>
> I seem to remember that bytea data was run through the multibute code
> for some reason, and I don't recall seeing th
[EMAIL PROTECTED] wrote:
> Chester Chee ([EMAIL PROTECTED]) reports a bug with a severity
> of 2 The lower the number the more severe it is.
>
> Short Description Old bug is back!! Drop database bug
>
> Long Description PostgreSQL version 7.2.1 running on RedHat 7.3 with
> all the latest pa
Bruce Momjian wrote:
> I am hoping for a patch for this for 7.3. Added to open items:
>
> Fix bytea to not encode input string
>
I said:
> Here's the remaining issue that I remembered; see:
> http://archives.postgresql.org/pgsql-hackers/2002-04/msg00256.php
>
> The gist of this is that w
Sean Chittenden wrote:
> Not a problem there. I walked around the code for a bit, made a few
> hacks to see how things are working, and I can tell you strait up that
> if you'd like this by 7.3, it won't be happening from me. <:~) I'm
> stretched kinda thin as is and don't think I'll be able to
fredrik chabot wrote:
> connection to server was lost
>
> I get more or less frequently.
>
> what to do?
Start by giving us more information.
What version of Postgres? What platform (Linux, etc)?
What does the relevant portion of your database schema look like?
What repeatable series of action
Ruslan A Dautkhanov wrote:
> Btw, how I can convert TEXT field to a CString one? I had tried to use
> char *cnum = PG_GETARG_CSTRING(0) instead of
> text tnum = PG_GETARG_NAME(0), but it's not worked properly. Is any function
> to convert text object to a null-terminated string??? Thanks ag
Elielson Fontanezi wrote:
> GRANT ALL on "recursos_materiais" to "user_fomacao_des"; --< Here is the
> point in question
[...snip...]
> REVOKE ALL on "recursos_materiais" from PUBLIC;
> GRANT ALL on "recursos_materiais" to "131"; --< What is it?
>
> Is that a bug?
It looks like someone dropped u
elein (by way of elein ) wrote:
> This will not work if there is no EOS on the data portion of the
> string. Text fields are not usually stored with the EOS on them,
> are they?
Yes, the TEXT data type is NULL terminated.
Joe
---(end of broadcast)
Kris Jurka wrote:
This behavior is present in 7.3 as well.
On Thu, 5 Dec 2002, Kris Jurka wrote:
Using the old < 7.3 version of dblink on 7.4devel gives a
"get_names_for_var: bogus varno 5" error.
I can confirm this both on cvs tip (pulled after noon PST today) and 7.3
stable branch. It is no
Tom Lane wrote:
Ah, thanks for the simplified test case. This is undoubtedly my fault
... will look into it. It is probably somewhat related to the join
alias problem found yesterday (ie, somebody somewhere is trying to use
the wrong rangetable list to interpret a Var node).
I spent a bit more
Mike Glover wrote:
Please enter a FULL description of your problem:
The docs state (section
23.9):
If a non-NULL value is returned then the operation proceeds with that row
value. Note that returning a row value different from the original value o
Andrzej Kosmala wrote:
PostgreSQL 7.3 on Linux
After dropping column functions return error message: "ERROR:
Query-specified return tuple and actual function return tuple do not match"
Hmmm, looks like nodeFunctionscan.c:tupledesc_mismatch needs to be
taught about attisdropped. I'll submit a pa
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>> Hmmm, looks like nodeFunctionscan.c:tupledesc_mismatch needs to be
>> taught about attisdropped. I'll submit a patch this evening if no
>> one else gets to it first.
>
> Actually, I believe I delibe
[EMAIL PROTECTED] wrote:
Daniel Brozek ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description problem with returning setof with double precision
values
Long Description I have got the table and the function (look at
example code). Afte
Andres Cuevas wrote:
If data1 or data2 are NULL the request is NULL
Which is the correct behavior, not a bug. See:
http://techdocs.postgresql.org/guides/BriefGuideToNulls
HTH,
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ
andrea gelmini wrote:
test=# SELECT * FROM sal_emp WHERE pay_by_quarter[1:4] *= 1;
ERROR: Unable to identify an operator '*=' for types 'integer[]' and 'integer'
You will have to retype this query using an explicit cast
There's nothing wrong with the docs (well, at least not with respe
Marcus England wrote:
Grants do not work at the database level using the syntax mentioned in
the documentation. i.e.:
GRANT ALL ON DATABASE dbname TO GROUP groupname;
Or
GRANT ALL ON DATABASE dbname TO username;
Works here:
regression=# select version();
version
---
Marcus England wrote:
IMHO, this is confusing and limiting for Administrators who wish to
grant privileges beyond CREATE, TEMPORARY, and TEMP across all tables in
a database. Something I believe most, if not all other DBMS's do. "ALL"
isn't very consistent.
Again, I don't know what your definition
Tom Lane wrote:
Bertrand Petit <[EMAIL PROTECTED]> writes:
When updating a NULL cell which is an array of something,
setting an adressed member of a non existent array, the value of the
cell is not changed.
Assigning to a member of a NULL array has always yielded another NULL
array. While
Branden R. Williams wrote:
POSTGRESQL BUG REPORT TEMPLATE
Your name : Branden R. Williams
Your email addres
Alvaro Herrera Munoz wrote:
On Tue, Oct 28, 2003 at 04:48:59PM -0500, Tom Lane wrote:
AFAICT there was no discussion about this issue when the patch was
proposed and applied. But now that the point is raised I have to say
that I don't like this change. I don't think system catalogs should be
excl
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I think we should fix it but not force an initdb ---
information_schema is new and I am not sure how many people are using
it.
Yeah, I'm leaning that way too. We could publicize a script to fix the
problem in any beta5 or RC1 databases tha
Vernon Smith wrote:
When I try to delete data from one table, I get this error:
ERROR: get_typdefault: failed to lookup type 0
I can't find any reasons other than a bug. The PG version is 7.3.4
And neither can we without some details.
Please post the results of
\d tablename
, the definitions o
Alvar Freude wrote:
PostgreSQL 7.3.4 on i386-portbld-freebsd4.8, compiled by GCC 2.95.4
begin;
create table test (b bytea);
create index tst_idx on test(b);
insert into test values ('\001abc\006');
insert into test values ('\001xabc\006');
insert into test values ('\001\002abc\006')
PostgreSQL Bugs List wrote:
The following bug has been logged online:
Bug reference: 1000
Logged by: Dave Page
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.5 Dev
Operating system: FreeBSD www.postgresql.com 4.8-STABLE FreeBSD 4.8-STABLE #5: Sat Sep 20 14:56:14 ADT 2
David Fetter wrote:
I have a little puzzlement. In the first select, I double the
backslash and return true. In the second, I don't and get false.
Have I missed something important in the docs?
I don't know if it is clear in the docs anywhere wrt regex, but the
string literal parser will consume
Joe Conway wrote:
David Fetter wrote:
I have a little puzzlement. In the first select, I double the
backslash and return true. In the second, I don't and get false.
Have I missed something important in the docs?
I don't know if it is clear in the docs anywhere wrt regex, but the
stri
Tom Lane wrote:
We could fall back in that direction if we had to. But I'd like to
understand why we have to, first. Gen_fmgrtab.sh has worked on all our
supported platforms for a long time, and I'm disinclined to assume that
it's suddenly broken ... especially on what's presumably a modern
platf
PostgreSQL Bugs List wrote:
This application has failed to start because mspdb71.dll was not
found. Re-installing the application may fix this problem.
This has nothing to do with Postgres. "mspdb71.dll" is part of Visual
Studio .Net -- look in:
"c:\Program Files\Microsoft Visual Studio .NET 2003\
cases like this.
But I don't see an inherent reason why "raise an error" is better than
"return a null array".
In fact, the above referenced thread shows a scenario where the former
behavior is unpleasant.
I think Joe Conway is planning to tackle that underlying misfeatur
Dennis Bjorklund wrote:
On Thu, 15 Jan 2004, Joe Conway wrote:
Additionally, this behavior was discussed during the 7.4 development and
beta cycles on at least a couple occassions -- that would have been the
time to complain, not now.
Well, I will complain whenever I see something I don't
Josh Berkus wrote:
Bug: Cannot Use Arrays with Raise Notice in PL/pgSQL.
Version Tested: 7.4.1
Severity: Annoyance
Description:
Attempting to pass an array element to Raise Notice in PL/pgSQL will produce a
parse error:
I can reproduce this with cvs tip -- I'll check into it.
Thanks,
Joe
--
Tom Lane wrote:
Right now I think the sanest behavior would be to throw an error on
non-rectangular input. Once we have support for null elements in
arrays, however, it would arguably be reasonable to pad with NULLs
where needed, so that the above would be read as
{{1,2},{2,3},{4,NULL}}
PostgreSQL Bugs List wrote:
In INSERT statements the string '{}' is correctly parsed as an empty array
when '{ }' is not, as if the space was signifiant, and generates a syntax
error.
Also
'{"A", "B"}' will be correctly parsed when
'{"A", "B" }' (note the space before the closing brace ) will
Tom Lane wrote:
"Ezequiel Tolnay" <[EMAIL PROTECTED]> writes:
I've created the cardnumber_t datatype, which is an int8, to provide
implicit typecasting with varchar padding the result with zeroes.
Conversions work as expected between int4, int8, cardnumber_t and varchar.
They also work fine between
hint:
auth-method
Also read:
http://www.postgresql.org/docs/8.4/interactive/contrib-dblink-connect.html
-and-
http://www.postgresql.org/docs/8.4/interactive/contrib-dblink-connect-u.html
HTH,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Train
9 ( id INTEGER PRIMARY KEY, val TEXT);
> INSERT INTO tab99 SELECT generate_series(1,1000),'xx';
> SELECT median(id) FROM tab99;
> COMMIT;
>
>
> We crash at commit.
>
> Changing median to something else (e.g avg or even a non PLR median
> functi
On 01/24/2013 08:01 PM, Mark Kirkwood wrote:
> Ah right - sorry, I did a quick look for a mail list on the plr web site
> and didn't spot anything.
No problem. It is plr-general on pgfoundry:
http://pgfoundry.org/mail/?group_id=1000247
Joe
--
Joe Conway
credativ LLC: http://www.
finish and investigating what's causing the first error
> call.
Yeah -- will do. Thanks!
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support
--
Sent via pgsql-bugs mailing list (pg
> Making use of this seems to fix the original bug - and possibly the
> SIGINT stealing too.
>
> Patch attached to set the variable (R_SignalHandlers = 0), and remove
> the SIGINT workaround.
Cool -- thanks. Maybe that got added in a release since last I looked.
Joe
--
Joe
the
documentation:
http://www.postgresql.org/docs/9.2/interactive/tablefunc.html
If you still have a problem please provide SQL that can be cut and
pasted which:
1) create your table
2) insert sample rows
Then show us what out put you are trying to acheive as output from
that data.
Joe
- --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/22/2013 04:17 PM, Joe Conway wrote:
> If you still have a problem please provide SQL that can be cut and
> pasted which: 1) create your table 2) insert sample rows Then show
> us what out put you are trying to acheive as output from th
73 matches
Mail list logo
