wrote:
> I have column(string datatype) has a data starting with single
> quote as below
>
> 'single resource to avoid all job execution'
>
> Now I want write select query to select records which starts with
> single quote.
>
> I tried with many option however could not get the result.
Thi
Tom Lane wrote:
> rl...@pablowe.net writes:
>> There is an edge case where Postgres will return an error to the
>> client, but commit the operation anyway, thus breaking the
>> contract with the client:
>
>> postgres=# begin; insert into s.t (c) values (1);
>> > not affected)>
>> postgres=# commi
wrote:
> colname = 'value' returns true but
> colname LIKE 'value' returns false.
Is the colname of type char(n) or does it contain trailing spaces?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
[rearranged to avoid top-posting: http://idallen.com/topposting.html]
Vipul Patel wrote:
> On Thursday 09 February 2012 10:33 PM, Kevin Grittner wrote:
>> What locks and blocking do you see when this happens?
>>
>> http://wiki.postgresql.org/wiki/Lock_Monitoring'
wrote:
> some time call of create table is stuck which is called by PQexec.
What locks and blocking do you see when this happens?
http://wiki.postgresql.org/wiki/Lock_Monitoring'
Have you considered getting an explicit lock with NOWAIT at the
start of your transaction, to test whether you
"Kevin Grittner" wrote:
> Andrew Alcheyev wrote:
>
>> Well, it does good and the backend hasn't crashed yet, but the
>> client is still experiencing query problems at some point (not
>> far, I guess, from where its backend would segfault without the
[moving to pgsql-www with bc to pgsql-bugs]
wrote:
> Your projects website is down (tried to visit the pgpool page),
> and I didn't know where else to report it.
People are aware of the site failure and hopefully someone with the
appropriate access permissions is looking into it.
If you wa
r d wrote:
> When I do this
>
> CREATE TABLE "*T1*"
> (
> "T1_ID" bigint NOT NULL,
> CONSTRAINT "*T1*" PRIMARY KEY ("T1_ID" )
> );
>
>
> I get the following message:
>
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> "T1" for table "T1"
> ERROR: relation "T1" already e
John Udick wrote:
> We did notice that although now() failed, changing this to
> 'now()'::date works (using single quotes around now()).
That seem unrelated to the now() function. Casting a literal to a
date/time/timestamp supports parsing out certain keywords, like
'now', 'today', 'yesterday
naveen wrote:
> backup process takes more time
How much?
> process is unsuccessful.
In what way? Is there an error message? If so, please paste it.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
Andrew Alcheyev wrote:
> Well, it does good and the backend hasn't crashed yet, but the
> client is still experiencing query problems at some point (not
> far, I guess, from where its backend would segfault without the
> patch). This time it encounters the following error from the
> backend:
>
wrote:
> PostgreSQL version: 8.4.1
You are missing years of bug fixes. You should be staying more
up-to-date on minor releases.
http://www.postgresql.org/support/versioning/
To review what has been fixed between 8.4.1 and 8.4.10, please look
through the links from 8.4.2 and up on this pag
wrote:
> postgres=# prepare foo as create table bar (c integer);
> ERROR: syntax error at or near "create"
> LINE 1: prepare foo as create table bar (c integer);
>^
>
> This error message does not in any way indicate that one cannot
> prepare a create table statement.
>
wrote:
> PostgreSQL version: 9.1.2
> Operating system: Mac OS X 10.6.8
> I didn't manage to download your product
>From where did you try to download it?
> Unable to create PostgreSQL database: PT3 DB
> Reason: Unable to login to database (template1). Reason: could not
> connect to server:
wrote:
> PostgreSQL version: 8.4.9
> Operating system: CentOS 5.7 on OpenVz (2.6.32-042stab044.11)
> LOG: server process (PID 30683) was terminated by signal 7: Bus
> error
> LOG: terminating any other active server processes
We've had a few reports like this lately, all on VMs. H
wrote:
> I downloaded the insatller of postgresql from the internet and
> when I try to install it says "Cannot install a 64 bit installer
> on a 32 bit platform".Where can I get a 32bit installed.
This is not a bug. Please post futures questions like this to a
more appropriate list, like pgs
Tom Lane wrote:
> On reflection what seems most likely is simply that turning these
> otherwise-inlineable SQL functions into SECURITY DEFINER disabled
> inline-ing them, resulting in catastrophic degradation of the
> generated plans, such that they took a lot longer than you were
> accustomed t
Tom Lane wrote:
> "Kevin Grittner" writes:
>> No comments on this?
>
> If there was a reproducible test case in your original message,
> I didn't see it, so I assumed you intended to investigate further
> on your own. It wasn't even clear to me that t
No comments on this? It seems to me that at a minimum this needs
better documentation of a limitation, and the conditions under which
you hit the problem. I'm not sure there isn't an outright bug here.
We would like to flag all of our trigger functions as SECURITY
DEFINER, but there are triggers
wrote:
> test to run: select to_timestamp('2011,03,27,02,11,11',
> ',MM,DD,HH24,MI,SS')
>
> and the run: select to_timestamp('2011,03,27,03,11,11',
> ',MM,DD,HH24,MI,SS')
>
> It miscalculates 02 hour to 03 hour by some reason
I don't know what time zone you're in, or whether daylight
wrote:
> calling into generate_series() within a 'returns int' (singular)
> SQL stored function doesn't raise error (plpgsql does):
>
> -- SQL function elides over fact that generate_series() is a SRF
> create function foo_sql()
> returns int as
> $$
> select * from generate_series(1,5)
> $$ lan
Cihan *ENGÜL wrote:
> Postgresql to wince VS2003 applications or open source code for
> the DLL, I needsupport.
This mailing list is for reporting bugs in the PostgreSQL code. To
advertise a position please post to pgsql-jobs. To look for a
contractor to provide support, check here:
http://
PostgreSQL version 9.0.4, 64 bit.
Linux version 2.6.16.60-0.39.3-smp (geeko@buildhost)
(gcc version 4.1.2 20070115 (SUSE Linux))
#1 SMP Mon May 11 11:46:34 UTC 2009
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2
We flagged some functions as SECURITY DEFINER and had queri
wrote:
> ODBC ANSI driver psqlODBC v09.00.0310.1 does not properly pass
> values when data is of type "INTERVAL" to Crystal Reports.
You might want to try posting this issue to the pgsql-odbc list.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to yo
wrote:
>INSERT INTO auftragpos (orderno,position,item) VALUES
> (testorder18,1,00123);
> brings error:
> FEHLER: Spalte *testorder18* existiert nicht (Column
> *testorder18* not exists)
> LINE 1: ...T INTO auftragpos (orderno,position,item) VALUES
> (testorder1...
>
> But *testorder18* is
wrote:
> Simply set a varchar field in your db to the following string:
> !"#$%'()*+,-/:;=?@[\]^_`{|}~&<>
Do you have standard_conforming_strings = on?
> The like command works fine up with escapes up to:
> !"#$%''()*+,-/:;=?@[%
> Notice, I added the % to the end. However, if you go any
"Roye Cohen" wrote:
> I found a degradation in physical memory used on DB server (~200%
> degradation)
What are you measuring, and what were the numbers?
> and a small degradation in response times on every transaction
> monitored in comparison to 9.0.
What transaction isolation level was
Mlungisi Sincuba wrote:
> To whom it may concern,
>
> like and ilke not working on postgresql 9.0.3. Bug fix is not
> mentioned on 9.0.5 either. The same statement works very well on
> postgresql 8.4.
They work for me.
Perhaps you used a different locale configuration under the new
version?
"mohsen" wrote:
> PostgreSQL version: 8.1
That's no longer a supported version. 8.2 goes out of support next
month. Please upgrade to something more recent.
> I use this command for create TEMPORARY TABLE
>
> now affter use this temporary i want DROP this Table but NOT WORk
> IF EXIST TE
"Jim Jackson (817) 233-2385" wrote:
> Does any of that help determine how to get rid of it?
It appears that they copied some documentation to your hard drive.
I imagine those pages look something like these:
http://www.postgresql.org/docs/8.4/static/release.html
http://www.postgresql.org/
"Jim Jackson (817) 233-2385" wrote:
> The postgreSQL was a separate installation step that had to be
> done separately from the poker software load to support the poker
> software.
The question is, where did you get the installation software for
that step? If you got it from the poker softwar
"Jim Jackson (817) 233-2385" wrote:
> So do you have an answer to this issue??? I have not heard from
> anyone.
Your reply to Craig did not show up on the list. Did you "reply
all" when you sent it? If you did, the screen shots you mentioned
might perhaps have caused the post to be filtered
goudvis wrote:
> Robert Haas wrote:
>>
>> I would be curious to see (updated, corrected) results on older
>> versions.
>
> If I am correct, Kevin Grittner is writing a review of the code
> and the testing methods. I think it would be wise to wait for the
> out
goudvis wrote:
> The report is based on a java application that can be found here:
> http://dl.dropbox.com/u/19316575/dbtp.zip. This zip-file also
> includes an SQL file that creates the used tables and the queries
> that are executed.
>
> I put a README-file in the zip with installation instruct
"Paul Stapersma" wrote:
> PostgreSQL version: 8.3.3
> A full report on our findings can be found here:
> http://dl.dropbox.com/u/19316575/report.pdf
I would like to independently run your tests, but I don't see
anything in the paper to describe the table(s) used or how they were
populated.
Tom Lane wrote:
> I think it wouldn't be an unreasonable thing to just interpret a
> SELECT with no INTO clause as being a PERFORM (ie execute and
> discard results).
FWIW, that would probably confuse people coming from MS SQL Server
or Sybase ASE, since doing that in Transact-SQL would return
"Vishnu S." wrote:
> I have created index on some of the tables in the custom
> tablespace. But the indexes resides in the default tablspace. Is
> there any issue in it?
No.
> Is there any chance for deleting the tablespace, if the crash
> recovery using WAL and fsync is failed?
I don't kn
"Vishnu S." wrote:
> I am using PostgreSQL 8.4 in windows. I have created a database
> and some tables on it. Also created a table space and some tables
> in it. My application inserts data into these tables in every
> second. The application is a continuous running application. My
> issue is
wrote:
> 1.drop database 'postgres'
> 2.create a database by createdb.exe
> the follow error message will dispaly:
> Can not create DB by 'createdb.exe' when database 'postgres' is
> droped
To create a database, the createdb executable has to connect to the
cluster. A connection is always to
Susannah wrote:
> FATAL: conversion between WIN1252 and LATIN1 is not supported
WIN1512 supports characters which are not supported by LATIN1. If
you sent such characters to the database, what would you expect to
happen?
> I can connect through pgAdmin and create tables etc, just not with
Yaamini Bist wrote:
> Does that means it's supported as well on RHEL6.1 if we face issues
> in future?
Since this is not a bug, please post any further discussion of this
on a more appropriate list, like pgsql-general.
You should probably review these pages, and see if you still have
questio
wrote:
> I've encountered some problems with the updated ENUM in PosgreSQL
> 9.1:
No matter how I tilt my head, I can't see any of those issues as
bugs. You have two feature requests and a question about how to
work around problems you're having with direct modifications to the
system tables.
Tom Lane wrote:
> it would be interesting to know what Oracle etc do with NaN and
> Infinity, assuming they even support such numbers.
>
> Currently what our code does for the format-with- case is to
> output "#" in all digit positions. It would be plausible for that
> to happen in the non
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Christopher Gernon wrote:
>>> to_char() should be able to convert 5.6e-32 to text just as
>>> easily as it can convert 5.6e-3. For some reason, it doesn't.
>
>> Oh, I see your point now, and I agr
Christopher Gernon wrote:
> to_char() should be able to convert 5.6e-32 to text just as easily
> as it can convert 5.6e-3. For some reason, it doesn't.
Oh, I see your point now, and I agree with you.
We should probably at least put this on the TODO list, I think. Any
objections?
-Kevin
-
"Chris Gernon" wrote:
> The to_char() function gives incorrect output for float values
> whose decimal expansion has several digits (more than somewhere
> around 14-15) after the decimal point.
These are approximate data types. On what basis do you think the
values returned in your examples a
"Albert Ward" wrote:
> would like to translate it to Bulgarian language, so I can share
> it with the readers on my blog.
This is not a bug, so it doesn't belong on this list. I will reply
to the duplicate post on docs shortly.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgr
Jan Snelders wrote:
> I wrote small java program which performs some selects in one
> transaction (and thread) and one delete in another transaction and
> thread on the same table holding one record initially.
> The DELETE transaction commits.
> The program now selects and
> prints the record
"Kevin Grittner" wrote:
> test=# select val from (select 'a' = 'a') as val;
> val
> -
> (t)
> (1 row)
Also note the difference between a record and a scalar here. I
forgot to write it to return val as a scalar, which seems to be what
you
Alexey Klyukin wrote:
> On Aug 29, 2011, at 5:02 PM, Kevin Grittner wrote:
>
>> Alexey Klyukin wrote:
>>
>>> Function calls can appear in the FROM clause. (This is
>>> especially useful for functions that return result sets, but any
>>> function
Alexey Klyukin wrote:
> Function calls can appear in the FROM clause. (This is especially
> useful for functions that return result sets, but any function can
> be used.) This acts as though its output were created as a
> temporary table for the duration of this single SELECT command.
It doesn
Merlin Moncure wrote:
> yeah, that's the correct way, but why does this work?
> select val from random() as val;
If you look at the PostgreSQL reference docs for the SELECT
statement, a from_item can be a SELECT statement in parentheses or a
function call (among other things). It cannot be an
Alexey Klyukin wrote:
> The following statement produces an error message in PostgreSQL 8.4
> - 9.2 (head):
>
> postgres=# select val from random()::integer as val;
> The same statement rewritten with CAST AS works as expected:
>
> postgres=# select val from CAST(random() as integer) as val;
Claudio Oliveira wrote:
> I'm doing the test in PGAdmin.
>
> Must be a bug in PGAdmim.
>
> I'm sorry I have not tested in psql
>
> create table txt (val text);
> txt insert into values (repeat ('x', 4500));
> char_length select (val) from txt;
> txt insert into values (repeat ('x', 4685))
"Claudio Oliveira" wrote:
> Use version 8.4 and have no issues with the field type TEXT.
>
> In version 9.1rc1 is limited to 4680 characters.
>
> Where do I change that size?
test=# create table txt (val text);
CREATE TABLE
test=# insert into txt values (repeat('long string', 100));
INSE
"Robert Hopek" wrote:
> Why do you have the configuration option to change the pgsql
> socket (which we need to do for our jailed shell environment), but
> not have psql check the postgresql.conf file for the enablement of
> that location change so that psql would look there automatically?
We
"ai" wrote:
> Oops.. I just saw, that I send you "correct" (already with
"workaround")
> sql-code instead of "wrong"...
> here is "wrong" (difference is in "SELECT sub3.key3, sub4.value2
FROM" ):
OK, that is still happening, and looks wrong to me. The outermost LEFT
JOIN is between this:
"listar" wrote:
> PostgreSQL version: 8.4.5
> Description:wrong result with nested left-joins
> And this is the problem - value2 can't be NULL because of COALESCE
> in sub4 (at least I think that it can't be =))
This works correctly in release 9.0.4 and development HEAD. I
don't st
"Shivakumar Ramannavar" wrote:
> Though my table is empty, pg_relation_size(name) return 38 MB.
This is unlikely to be a bug, although without more information it's
hard to be sure. Please post any follow-ups on the identical post
you put on another list. And please don't cross-post like tha
"Snehad Agrekar" wrote:
> the server doesen't accept connections: the connection library
> report could not connect to server: connection
> refused(0x274D/10061) is the server running on host
> "localhost" and accepting tcp/ip connection on port 5432?
This is not a bug. It would be more a
Glonet NV / Mathieu Aras wrote:
> Can we install PostgreSQL 8.4 on a server 2008? Is it X64 and X32
> compatible?
This is not a bug. A more appropriate list for this question would
have been pgsql-general.
I'm not sure what "server 2008" is, but if it's some form of
Windows, version 8.4 sh
"Gene Lum" wrote:
> PostgreSQL version: 9.0
> Operating system: Windows 7 (32-bit)
> I tried to import an output tar file from pg_dump (same version)
> using pg_restore. I can import using the command line without
> problem. I can also execute the command through a Java process by
> specifyi
"Arne Scheffer" wrote:
> Sorry, missed to fill out this form, please see
>
> http://archives.postgresql.org/pgsql-bugs/2011-07/msg00172.php
As mentioned in the reply to that post, this is not a bug.
You can wait for autovacuum to fix things up, or run VACUUM ANALYZE
against the database. I
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> The update causes the already-selected target row version of the
>>> DELETE to be obsoleted, so heap_delete finds it has nothing to
>>> do. I'm disinclined to mess with that
Tom Lane wrote:
> "Kevin Grittner" writes:
>> [ circular trigger relationships ]
>
>> I expect the DELETE from a to delete related b record(s) and then
>> succeed. Instead the UPDATE in b_del_trig causes delete of a to
>> silently fail.
>
> The
The following bug has been logged online:
Bug reference: 6123
Logged by: Kevin Grittner
Email address: kevin.gritt...@wicourts.gov
PostgreSQL version: HEAD and 9.0.4
Operating system: Linux (probably doesn't matter)
Description:DELETE fails if before trigger c
"Wiesiek" wrote:
> Description:Bad path
> When I try to backup i have a problem.
> \"alfaCC2\"
> I have to do the backup manually from the console and correct
> entry.
"Manually from the console" as opposed to what?
What "entry" do you correct? In what way?
> Where can improve
"sravan" wrote:
> Description:how db is stored
> i want to know how quires are going to write
> send me some examples
This doesn't sound even a little bit like a bug report. If you have
questions, the pgsql-novice or pgsql-general list would be more
appropriate.
Before sending an
"Pilling, Michael" wrote:
> The real problem here then is that the documentation showing
> the boolean comparison operators does not mention this
This page does, at length:
http://www.postgresql.org/docs/9.0/interactive/functions-comparison.html
What page are you looking at?
> And indeed
* ** wrote:
> 17.06.2011, 00:28, "Kevin Grittner" :
>> * **; wrote:
>>
>>> [4-1] 2011-06-16 17:40:27 UTC LOG: startup process (PID 15292)
>>> was terminated by signal 7: Bus error
>>> Signal 7 means hardware problems
"Michael Pilling" wrote:
> A reasonable programmer would expect != NULL, <> NULL and IS NOT
> NULL to be synonyms.
Only if that programmer was not aware of the SQL standard and had
not worked much with a standard-conforming database.
NULL is conceptually intended to indicate "unknown" or "no
* ** wrote:
> [4-1] 2011-06-16 17:40:27 UTC LOG: startup process (PID 15292)
> was terminated by signal 7: Bus error
> Signal 7 means hardware problems. But all 10 replicas crashed
> within 10 minutes, say from 13:35 to 13:45.
> One important thing - all replicas and master are
Alvaro Herrera wrote:
> Would it be possible to dump USING as an equivalent ON condition
> on output (nodeToString), and then examine simple ON conditions to
> turn them into USING conditions on input (stringToNode)?
You know, I'm not necessarily against some warning that a USING
clause in a v
Robert Haas wrote:
> Tom Lane wrote:
>> Personally my advice is to avoid USING: it wasn't one of the SQL
>> committee's better ideas.
>
> I don't understand why we can't just translate the USING into some
> equivalent construct that doesn't involve USING. I proposed that
> a while ago and you
"jose soares" wrote:
> Description:why a REAL should be queried as a string?
> I'd like to to report this strange behavior, that I think is a
> bug...
>
> # \d frazione
> Table "public.frazione"
>Column | Type | Modifiers
> +-+--
"Martin A. Brooks" wrote:
> My current $dayjob is working in an industry where details and
> aesthetics are everything. We will spend thousands of hours of
> processor time just to make sure than the sheen on an animal's fur
> will suggest "healthy and luxuriant" rather than "warm and moist".
>
"Jai Kumar Shamra" wrote:
> Description:Automatically generated sequence number jumps.
> We are facing problem of automatically sequence number changes in
> increasing order, why?
Probably transactions rolled back or someone used the setval
function. From the manual:
http://www.po
"Brian" wrote:
> I need to connect Postgres SQL to Excel 2010 Power Pivot
>
>
> Please help on instructions
This is not a bug. Try posting to pgsql-general, or if you expect
that it will use ODBC you could post on pgsql-odbc. When starting a
new thread, it's best to look at this page and c
"Michiel" wrote:
> [query with ORDER BY clause]
> [plan which spends 0.039 ms sorting one row]
> What i see and expect:
>
> I see that the query is sorted. But the result is max 1 item.
This is not a bug; it is a feature request for the planner.
If you see a way that a query can be reli
Please keep the list copied. I'm moving this to the pgsql-admin
list (with a blind copy to -bugs), since there is really no hint of
a PostgreSQL bug here, except possibly in terms of how we document
this issue.
Suprabhat Mohapatra wrote:
> Should I send you the sample code that we are using
"Suprabhat" wrote:
> FATAL: too many connections already and there are too many
> postgres processes on the server. We have used connection
> pooling methods after unsuccessfully using pgpool2.
Is there a thread somewhere where you were trying to get help
configuring pgpool?
> Probably we ar
Jon Nelson wrote:
> Would the following query be more (most?) correct, assuming the
> oid of the table is known?
It doesn't seem to work for indexes on expressions.
Try this:
create table t (id int not null primary key, txt text);
create index t_weird on t ((substring(txt, 1, id)));
create
Lawrence Cohan wrote:
> We managed to put together a new test server running PG 9.0.2 on
> 2socketsx6cores = 12CPU with 64 GB RAM against a 3PAR 10TB SAN. We
> kept the settings I submitted already (and enclosed below) and
> after 12 hours of pounding the box with PGBENCH running 8 scripts
> to
Jeff Wu wrote:
> what needs to happen to get this fix in?
Well, "fix" implies that there is a bug, which there isn't. The
current behavior doesn't violate the requirements of the standard,
nor is it a regression from the behavior of any previous PostgreSQL
release. What we're talking about i
Heikki Linnakangas wrote:
> The immediate fix is trivial:
>
> [patch changing one line of code]
I have confirmed that without this patch the new regression tests I
have proposed will fail, and with the patch they succeed. I have
also confirmed that the isolation test suite continues to succe
"Allen Sooredoo" wrote:
> we are facing a performance issue on Postgres 8.4, the CPU reaches
> 100% with less than 50 simultaneous users.
>
> We were thinking to migrate the HR system from Oracle to Postgres
> but now that we have those big performance problems on relatively
> small application
Tom Lane wrote:
> "Kevin Grittner" writes:
>> If I'm reading this correctly, it would appear that nobody has
>> updated anything to a TOASTed value in a build against HEAD in
>> testing *anything* in the last two and a half months. And the
>> regressio
Tom Lane wrote:
> Hmm, is there much regression coverage for TOAST inserts or
> deletes either?
I'll check.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
> Egad. If that's it, my confidence in the amount of testing SSI
> has gotten has just dropped dramatically.
If I'm reading this correctly, it would appear that nobody has
updated anything to a TOASTed value in a build against HEAD in
testing *anything* in the last two and a h
Heikki Linnakangas wrote:
> But the question Tom raised about doing this even for
> non-serializable transactions is more serious..
This particular call from heapam.c went in much later than most of
the code, since we had trouble proving that anything needed to be
done there in the first place
Heikki Linnakangas wrote:
> On 20.04.2011 17:26, Tom Lane wrote:
>> Why is predicate.c getting called at all when
>> transaction_isolation is not SERIALIZABLE? (Although the same
>> crash happens when it is ...)
>
> Because another serializable transaction that reads/updates the
> tuple later
"Marko Tiikkaja" wrote:
> TRAP: FailedAssertion("!(((bool) (((void*)(&(newTuple->t_self)) !=
> ((void *)0)) && ((&(newTuple->t_self))->ip_posid != 0", File:
> "predicate.c", Line: 2282)
Am investigating, and have alerted Dan, in case he hasn't noticed
this thread.
-Kevin
--
Sent via pg
"Daniel Migowski" wrote:
> I would love to give pg_dump an option to produce ordered output.
This is a feature request, not a bug -- so this list is not the
right place to discuss it. A discussion like this would be more
appropriate on the pgsql-general list. When starting a new thread,
it m
Merlin Moncure wrote:
> Consider we also have to send data to the database. I can
> recursively wrap up data in the client using libpqtypes, fire it
> to a receiving function which unnests it and processes it. This
> is a couple of orders of magnitude faster than streaming it in
> over multipl
Merlin Moncure wrote:
> There are lots of use cases for this. I use composite types to
> marshal data to the client all the time, and recursive structures
> are fairly common in many classic problems. Recursive composites
> fit the bill perfectly.
I'm trying to get my head around why SQL com
Rikard Pavelic wrote:
> On 15.4.2011 21:06, Tom Lane wrote:
>> The former.
>>
>> regression=# CREATE TYPE turtle AS
>> (
>> name varchar
>> );
>> CREATE TYPE
>> regression=# ALTER TYPE turtle ADD ATTRIBUTE offspring turtle;
>> ERROR: composite type turtle cannot be made a member of itself
>> reg
"Kevin Grittner" wrote:
> Mark Kirkwood wrote:
>
>> Here's a simplified example using synthetic data (see attached to
>> generate if desired):
>
> Doesn't work for me:
Edited scripts to change hard-coded directory. Issue confirmed.
> If
Mark Kirkwood wrote:
> Here's a simplified example using synthetic data (see attached to
> generate if desired):
Doesn't work for me:
kgrittn@kgrittn-desktop:~/work/starjoin$ ./gendata.pl
generate cat
cannot open cat.dat: No such file or directory at ./gendata.pl line
17.
> Here's what a p
Tom Lane wrote:
> "Kevin Grittner" writes:
>> That means that all three of the databases you tested have
>> extensions to the standard similar to what is being contemplated
>> for PostgreSQL.
>
> Uh, no, it proves they all extend the standard to allow NULL
Mike Fowler wrote:
> So to summarise, Oracle and PostgreSQL need minor tweaks to run
> cleanly and SQLServer and MySQL do not.
The FROM DUAL in Oracle has nothing to do with the issue at hand.
That is just because they always require a FROM clause on every
SELECT. DUAL is a special table wit
101 - 200 of 533 matches
Mail list logo