Ühel kenal päeval, K, 2006-05-17 kell 20:17, kirjutas Jonah H. Harris:
> On 5/17/06, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> > Does ADA have both assignment and comparison as operators, or is
> > assignment a statement ?
>
> Yes. Assignment is := and comparison is =
I meant to ask, if := is a
Quite a few buildfarm members are failing with variants of "Undefined
symbol: _canonicalize_path" in libpq. I think your recent patch that
calls canonicalize_path from fe-connect.c is misguided in the first
place; you certainly didn't ask for any discussion before applying it.
Bruce Momjian writes:
> Zeugswetter Andreas DCP SD wrote:
>
> > I thought the suggested procedure (see migration doc) was to use the
> > new pg_dump to dump the older db version, so why backpatch ?
>
> Uh, you can suggest it, but I would guess < 50% do it, and once the old
> database is gone, t
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Which means we need all the interface bits to be able to tell PostgreSQL
> where every single temp storage area is. Presumably much of the
> tablespace mechanism could be used for this, but it's still a bunch of
> work. And you can't just say "I have 8
On 5/17/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
>> (No, I'm not particularly in favor of the BY feature mentioned upthread,
>> either.)
> mmm... and why is that?
Essentially because it's not in the upstream language. Oracle could
come out with the s
Hackers,
We could really use a couple more Mentors for Google Summer of Code Projects.
Particularly, we've had some good proposals in these areas:
ECPG Cleanup
XML Support
Application development (mod_pyton)
Aggregation Improvements (multi-column, or non-sorting, or hash-based)
If you are inte
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Even C doesn't use the same operator for assignment and comparison.
However, SQL *does*, so it seems to me that plsql is gratuitously
inconsistent with its larger environment.
regards, tom lane
---(end o
Added to TODO:
* Add a GUC to control whether BEGIN inside a transcation should abort
the transaction.
---
Jaime Casanova wrote:
> On 5/12/06, Mario Weilguni <[EMAIL PROTECTED]> wrote:
> > Am Donnerstag,
On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
What is the best way to go about creating a "plug and play,"
PostgreSQL
replacement for MySQL? I think the biggest problem getting PostgreSQL
accepted is that so much code is available for MySQL.
http://pgfoundry.org/projects/mysqlcompat/
Mark Woodward wrote:
> Sorry to interrupt, but I have had the "opportinuty" to have to work with
> MySQL. This nice little gem is packed away in the reference for
> mysql_use_result().
>
> "On the other hand, you shouldn't use mysql_use_result() if you are doing
> a lot of processing for each row
Sorry to interrupt, but I have had the "opportinuty" to have to work with
MySQL. This nice little gem is packed away in the reference for
mysql_use_result().
"On the other hand, you shouldn't use mysql_use_result() if you are doing
a lot of processing for each row on the client side, or if the out
On 5/17/06, Hannu Krosing <[EMAIL PROTECTED]> wrote:
Does ADA have both assignment and comparison as operators, or is
assignment a statement ?
Yes. Assignment is := and comparison is =
Maybe we need just pl/ADA ;) ?
Wouldn't hurt :)
--
Jonah H. Harris, Software Architect | phone: 732.331
Stephan Szabo wrote:
> On Wed, 17 May 2006, Tom Lane wrote:
>
>
>>Stephan Szabo <[EMAIL PROTECTED]> writes:
>>
>>>Per the report from Clark C Evans a while back and associated discussion,
>>>it seems like recent versions of the SQL spec changed the rules for
>>>foreign key column references such
On Tue, 9 May 2006, Max Khon wrote:
Yes, there seems to be an awful lot of noise being made about the fact that
the system does, in fact, work exactly as documented, and that the
configuration being complained about is one that is specifically documented
as being unsupported and undesirable.
Ühel kenal päeval, K, 2006-05-17 kell 17:51, kirjutas Jonah H. Harris:
> On 5/17/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > Pascal is not the direct ancestor of PL/SQL, Ada is, and it uses := for
> > constant initialisation.
Does ADA have both assignment and comparison as operators, or is
a
On Wed, May 17, 2006 at 05:44:22PM -0400, Greg Stark wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > On Wed, May 17, 2006 at 12:55:53PM -0400, Greg Stark wrote:
> > >
> > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > >
> > > > Only if those spindles weren't all in a single RAID arra
On 5/17/06, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Pascal is not the direct ancestor of PL/SQL, Ada is, and it uses := for
constant initialisation.
True dat. Almost all PL/SQL components come from ADA.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, May 17, 2006 at 12:55:53PM -0400, Greg Stark wrote:
> >
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >
> > > Only if those spindles weren't all in a single RAID array and if we went
> > > through the trouble of creating all the machinery s
Hannu Krosing said:
>
> * = is used in CONST declaration in PASCAL, whereas pl/pgSQL
> documents := (i.e. ASSIGNMENT) for const declaration
Pascal is not the direct ancestor of PL/SQL, Ada is, and it uses := for
constant initialisation.
cheers
andrew
---(end of broadc
Ühel kenal päeval, K, 2006-05-17 kell 16:31, kirjutas Andrew Dunstan:
> Hannu Krosing wrote:
> >> I don't think too many people are using that functionality intentionally;
> >> I
> >> probably write more PL/pgSQL than anyone and would regard any assignment
> >> without ":=" as a bug.
> >>
>
Moving to -hackers.
On Wed, May 17, 2006 at 12:13:49PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > pg_dump -Fc | pg_restore will only match the output of pg_dump if
> > everything's the same version though, right? Or wrong? What happens if
> > pg_dump -Fc is and older v
Hannu Krosing wrote:
I don't think too many people are using that functionality intentionally; I
probably write more PL/pgSQL than anyone and would regard any assignment
without ":=" as a bug.
I do occasionally write some pl/pgSQL, and have at some points written a
lot of it. And most of
On Wed, May 17, 2006 at 10:55:19PM +0300, Hannu Krosing wrote:
> ??hel kenal p??eval, K, 2006-05-17 kell 10:01, kirjutas Jim C. Nasby:
> > If we're going to consider table-level compression, ISTM the logical
> > first step is to provide greater control over TOASTing; namely
> > thresholds for when
On Wed, May 17, 2006 at 10:18:51AM -0700, Josh Berkus wrote:
> Tom,
>
> > If you only care about Oracle to PostgreSQL (and who wouldn't?), then ?
> > it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
>
> I agree with David here. We care about the ability to migrate PL/SQL -->
Ühel kenal päeval, K, 2006-05-17 kell 10:22, kirjutas Josh Berkus:
> Tom,
>
> > True, but there were clear benefits from doing so. Disallowing "="
> > assignment in plpgsql wouldn't buy anything, just break programs.
>
> But it's already disallowed in most places. The i = i + 1 seems to be an
Ühel kenal päeval, K, 2006-05-17 kell 10:01, kirjutas Jim C. Nasby:
> If we're going to consider table-level compression, ISTM the logical
> first step is to provide greater control over TOASTing; namely
> thresholds for when to compress and/or go to external storage that can
> be set on a per-fiel
On Wed, May 17, 2006 at 12:16:13PM -0400, Rod Taylor wrote:
> > Actually, I suspect in most cases it won't matter; I don't think people
> > make a habit of trying to sort their entire database. :) But we'd want
> > to protect for the oddball cases... yech.
>
> I can make query result sets that are
On Wed, May 17, 2006 at 12:55:53PM -0400, Greg Stark wrote:
>
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > Only if those spindles weren't all in a single RAID array and if we went
> > through the trouble of creating all the machinery so you could tell
> > PostgreSQL where all those spindles
Greg Stark <[EMAIL PROTECTED]> writes:
> The ideal way to handle the situation you're describing would be to interleave
> the tuples so that you have all 1000 values of the first column, followed by
> all 1000 values of the second column and so on. Then you run a generic
> algorithm on this and it
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > We already do expose it:
> >
> > $ pg_config --sysconfdir
> > /usr/var/local/postgres/etc
> >
> >
>
> Speaking of this item, what do we want to do about the Windows situation
> where if the directory doesn't exist it reports nothing at a
Bruce Momjian wrote:
We already do expose it:
$ pg_config --sysconfdir
/usr/var/local/postgres/etc
Speaking of this item, what do we want to do about the Windows situation
where if the directory doesn't exist it reports nothing at all? I am
inclined to send back the outpu
Larry Rosenman wrote:
> Tom Lane wrote:
> > "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> >>> Uh, it is an _admin_ function, not an application programmer
> >>> function.
> >
> >> but libpq is the only thing that knows where it is, and I had
> >> proposed a way for psql to use the function to get
Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> >> Uh, it is an _admin_ function, not an application programmer
> >> function.
>
> > but libpq is the only thing that knows where it is, and I had proposed a
> > way for psql to use the function to get it.
>
> It'd make more sense f
Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
>>> Uh, it is an _admin_ function, not an application programmer
>>> function.
>
>> but libpq is the only thing that knows where it is, and I had
>> proposed a way for psql to use the function to get it.
>
> It'd make more sense for p
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
>> Uh, it is an _admin_ function, not an application programmer
>> function.
> but libpq is the only thing that knows where it is, and I had proposed a
> way for psql to use the function to get it.
It'd make more sense for pg_config to expose this as o
Josh Berkus writes:
>> True, but there were clear benefits from doing so. Disallowing "="
>> assignment in plpgsql wouldn't buy anything, just break programs.
> But it's already disallowed in most places.
No it isn't. The plpgsql scanner treats := and = as *the same token*.
They can be interch
Tom,
> True, but there were clear benefits from doing so. Disallowing "="
> assignment in plpgsql wouldn't buy anything, just break programs.
But it's already disallowed in most places. The i = i + 1 seems to be an
exception.
So what happens to "i" if I do:
IF i = i + 1 THEN
does "
Bruce Momjian wrote:
> Larry Rosenman wrote:
>> Bruce Momjian wrote:
>>> Larry Rosenman wrote:
Bruce Momjian wrote:
> Larry Rosenman wrote:
>> Tom Lane wrote:
>>> Bruce Momjian writes:
I thought about this. Attached is a patch you can use to
popen("pg_config") a
Larry Rosenman wrote:
> Bruce Momjian wrote:
> > Larry Rosenman wrote:
> >> Bruce Momjian wrote:
> >>> Larry Rosenman wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> >> I thought about this. Attached is a patch you can use to
> >> popen("pg_config") and then look for the thr
Tom Lane wrote:
> Bruce Momjian writes:
> > True, but if you go per-option, I can see adding a lot of them. That
> > seemed more messy.
>
> If there actually were a lot of options being proposed for addition,
> maybe, but I only see one on the table.
Well, SSL is one, multibyte is another. I c
Tom,
> If you only care about Oracle to PostgreSQL (and who wouldn't?), then
> it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
I agree with David here. We care about the ability to migrate PL/SQL -->
PL/pgSQL. We do *not* care about the ability to migrate PL/pgSQL -->
Bruce Momjian wrote:
> Larry Rosenman wrote:
>> Bruce Momjian wrote:
>>> Larry Rosenman wrote:
Tom Lane wrote:
> Bruce Momjian writes:
>> I thought about this. Attached is a patch you can use to
>> popen("pg_config") and then look for the thread flag to
>> configure. One idea
Bruce Momjian writes:
> True, but if you go per-option, I can see adding a lot of them. That
> seemed more messy.
If there actually were a lot of options being proposed for addition,
maybe, but I only see one on the table.
regards, tom lane
---(e
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
> I had made a proposal to expose the path used for pg_service.conf.
I don't remember that anymore, but my question about it would be "what's
the use case?" I don't see a particularly good reason why an app would
need to know that, whereas it's prett
Tom Lane wrote:
> Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> Yeah, the last point seems like a killer objection :-(. It'd be
> >>> better to add some sort of libpq function to handle the issue.
> >>
> >> and when I've proposed libpq functions to expose compile-time
> >> constants, I've bee
Larry Rosenman wrote:
> Bruce Momjian wrote:
> > Larry Rosenman wrote:
> >> Tom Lane wrote:
> >>> Bruce Momjian writes:
> I thought about this. Attached is a patch you can use to
> popen("pg_config") and then look for the thread flag to configure.
> One idea would be to add this sa
Bruce Momjian writes:
>> Tom Lane wrote:
>>> Yeah, the last point seems like a killer objection :-(. It'd be
>>> better to add some sort of libpq function to handle the issue.
>>
>> and when I've proposed libpq functions to expose compile-time
>> constants, I've been shot down.
>>
>> How is th
Bruce Momjian wrote:
> Larry Rosenman wrote:
>> Tom Lane wrote:
>>> Bruce Momjian writes:
I thought about this. Attached is a patch you can use to
popen("pg_config") and then look for the thread flag to configure.
One idea would be to add this sample to our libpq documentation.
>>
Larry Rosenman wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> >> I thought about this. Attached is a patch you can use to
> >> popen("pg_config") and then look for the thread flag to configure.
> >> One idea would be to add this sample to our libpq documentation. The
> >> problem with the
Tom Lane wrote:
> Bruce Momjian writes:
>> I thought about this. Attached is a patch you can use to
>> popen("pg_config") and then look for the thread flag to configure.
>> One idea would be to add this sample to our libpq documentation. The
>> problem with the example is popen() overhead, pg_c
Andrew Piskorski <[EMAIL PROTECTED]> writes:
> Things like enums and 1 bit booleans certainly could be useful, but
> they cannot take advantage of duplicate values across multiple rows at
> all, even if 1000 rows have the exact same value in their "date"
> column and are all in the same disk bloc
Bruce Momjian writes:
> I thought about this. Attached is a patch you can use to
> popen("pg_config") and then look for the thread flag to configure. One
> idea would be to add this sample to our libpq documentation. The
> problem with the example is popen() overhead, pg_config not in $PATH, or
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Only if those spindles weren't all in a single RAID array and if we went
> through the trouble of creating all the machinery so you could tell
> PostgreSQL where all those spindles were mounted in the filesystem.
I think the way you do this is simply
Tom Lane wrote:
> Bruce Momjian writes:
> > Very clear. The issue is that I can't find any of these emitted by a
> > pg_dump version who's native backend doesn't understand them.
>
> So? We're not doing anything differently in that regard either. 8.2
> will understand the SET, what's the probl
On Wed, 17 May 2006, Tom Lane wrote:
> I'm more inclined to think that we've messed up the information_schema
> somehow ...
As usual, you're right. ;)
Actually, it wasn't precisely that we messed it up as much as the 99
defintion was wrong. It's pointed out in the 2003 schemata
incompatibilities
For all those people not subscribed to -patches (should appear in
archive soon), I just posted a patch there implemented zlib compression
for logtape.c. If people have test machines for speed-testing this sort
of stuff, please have at it.
You can also download it here:
http://svana.org/kleptog/tem
> Actually, I suspect in most cases it won't matter; I don't think people
> make a habit of trying to sort their entire database. :) But we'd want
> to protect for the oddball cases... yech.
I can make query result sets that are far larger than the database
itself.
create table fat_table_with_few
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Fri, May 12, 2006 at 08:38:07PM -0400, Bruce Momjian wrote:
> > Is this like detecting of libpq is SSL-enabled? I see PQgetssl(). Do
> > we need to add a libpq function to return true/false for threading?
> > Slony requires a thr
Stephan Szabo <[EMAIL PROTECTED]> writes:
> That seems like a very odd way to phrase that since just saying that the
> sets of column names are equivalent would be enough for that and all the
> extra words seem to only obscure the point.
As an example of clear well-written English, it certainly fa
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 17 May 2006, Tom Lane wrote:
>> where SQL2003 has
>>
>> If the specifies a > list>, then there shall be a one-to-one correspondence between the
>> set of s contained in that
>> and the set of s contained in the > list> of a
On Wed, 17 May 2006, Stephan Szabo wrote:
> On Wed, 17 May 2006, Tom Lane wrote:
>
> > Stephan Szabo <[EMAIL PROTECTED]> writes:
> > > Per the report from Clark C Evans a while back and associated discussion,
> > > it seems like recent versions of the SQL spec changed the rules for
> > > foreign
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, May 17, 2006 at 11:38:05AM -0400, Tom Lane wrote:
>> Note that a large part of the reason for the current logtape.c design
>> is to avoid requiring 2X or more disk space to sort X amount of data.
> Actually, I suspect in most cases it won't matt
On Wed, 17 May 2006, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Per the report from Clark C Evans a while back and associated discussion,
> > it seems like recent versions of the SQL spec changed the rules for
> > foreign key column references such that the columns of the refe
On Wed, May 17, 2006 at 11:38:05AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > What *might* make sense would be to provide two locations for pgsql_tmp,
> > because a lot of operations in there involve reading and writing at the
> > same time:
>
> > Read from heap while
> > I thought the suggested procedure (see migration doc) was to use the
> > new pg_dump to dump the older db version, so why backpatch ?
>
> Uh, you can suggest it, but I would guess < 50% do it, and once the
old
> database is gone, there is no way to re-do the dump.
But you can still load the
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> What *might* make sense would be to provide two locations for pgsql_tmp,
> because a lot of operations in there involve reading and writing at the
> same time:
> Read from heap while writing tapes to pgsql_tmp
> read from tapes while writing final versi
Bruce Momjian writes:
> Very clear. The issue is that I can't find any of these emitted by a
> pg_dump version who's native backend doesn't understand them.
So? We're not doing anything differently in that regard either. 8.2
will understand the SET, what's the problem?
Zeugswetter Andreas DCP SD wrote:
>
> > Very clear. The issue is that I can't find any of these emitted by a
> > pg_dump version who's native backend doesn't understand them.
> >
> > I assume that it is expected that a cross-db dump/reload will generate
> > errors, and it is done rarely for upgr
> Very clear. The issue is that I can't find any of these emitted by a
> pg_dump version who's native backend doesn't understand them.
>
> I assume that it is expected that a cross-db dump/reload will generate
> errors, and it is done rarely for upgrades, but I assume same-version
> dump/restore
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Per the report from Clark C Evans a while back and associated discussion,
> it seems like recent versions of the SQL spec changed the rules for
> foreign key column references such that the columns of the referenced
> unique constraint must be named in or
On Wed, May 17, 2006 at 10:11:39AM -0400, Tom Lane wrote:
> The lack of documentation is easily fixed ;-). I don't think this is
> icky enough to justify breaking all the existing functions we'd
> undoubtedly break if we changed it.
I thought the suggestion was to complain loudly (presumably duri
On Tue, May 16, 2006 at 07:56:25PM -0700, David Wheeler wrote:
> If you only care about Oracle to PostgreSQL (and who wouldn't?), then
> it in fact seems desirable for PL/pgSQL to be a superset of PL/SQL.
Oh, and PL/SQL is a lot more powerful than plpgsql. See packages for one
thing...
--
Jim C
On Tue, May 16, 2006 at 07:56:25PM -0700, David Wheeler wrote:
> On May 16, 2006, at 19:52, Tom Lane wrote:
>
> >Distant ancestors aren't particularly relevant here. What plpgsql
> >tries
> >to be is a ripoff^H^H^H^H^H^Hsincere flattery of Oracle's PL/SQL. If
> >modifying the loop variable is
On Wed, May 17, 2006 19:53, Martijn van Oosterhout wrote:
> The main problem with PQexec and co is that they don't really do very
> well if a single query produces multiple result sets. I'm not sure if
> it's defined whether you get the first or the last. In any case, if you
> want all the result
Tom Lane wrote:
> Bruce Momjian writes:
> > You mean dumping and reloading pg_dump output in 7.3 generates errors?
> > I didn't know. Can you give an example? I wasn't aware of that.
>
> Well, looking at the SETs already currently emitted:
>
> $ pg_dump -s regression | grep ^SET
> SET client_
On Wed, May 17, 2006 at 10:06:04AM +0200, Martijn van Oosterhout wrote:
> On Wed, May 17, 2006 at 09:45:35AM +0200, Albe Laurenz wrote:
> > Oracle's compression seems to work as follows:
> > - At the beginning of each data block, there is a 'lookup table'
> > containing frequently used values in
If we're going to consider table-level compression, ISTM the logical
first step is to provide greater control over TOASTing; namely
thresholds for when to compress and/or go to external storage that can
be set on a per-field or at least per-table basis.
--
Jim C. Nasby, Sr. Engineering Consultant
On Tue, May 16, 2006 at 06:48:25PM -0400, Greg Stark wrote:
> Martijn van Oosterhout writes:
>
> > > It might be easier to switch to giving each tape it's own file...
> >
> > I don't think it would make much difference. OTOH, if this turns out to
> > be a win, the tuplestore could have the same
Bruce Momjian writes:
> Zdenek Kotala wrote:
>> I'm interesting in problem "Allow commenting of variables in
>> postgresql.conf to restore them to defaults". And I need some clarify
>> of SET command behavior.
> DEFAULT in this case is session default, which might be the compiled in
> default,
Bruce Momjian writes:
> You mean dumping and reloading pg_dump output in 7.3 generates errors?
> I didn't know. Can you give an example? I wasn't aware of that.
Well, looking at the SETs already currently emitted:
$ pg_dump -s regression | grep ^SET
SET client_encoding = 'SQL_ASCII'; fai
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The lack of documentation is easily fixed ;-). I don't think this is
>> icky enough to justify breaking all the existing functions we'd
>> undoubtedly break if we changed it.
> We have tightened behaviour in ways much harder to fix i
Tom Lane wrote:
> Bruce Momjian writes:
> > The basic issue is that we need to set standard_conforming_strings to
> > 'off' for loading into newer releases, >= 8.2, but that SET command is
> > going to generate an error even dumping/loading into the same version of
> > PostgreSQL, like 7.3 to 7.3.
""Albe Laurenz"" <[EMAIL PROTECTED]>
> Tom Lane wrote:
...
> > If modifying the loop variable is disallowed in PL/SQL, I'm all for
> > disallowing it in plpgsql, otherwise not. Anyone have a
> > recent copy of Oracle to try it on?
>
> I tried this on Oracle 10.2.0.2.0 (which is the most recent ve
Bruce Momjian writes:
> The basic issue is that we need to set standard_conforming_strings to
> 'off' for loading into newer releases, >= 8.2, but that SET command is
> going to generate an error even dumping/loading into the same version of
> PostgreSQL, like 7.3 to 7.3. I don't think we want th
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Someone posted something on the DBD::Pg mailing list recently that
> made me wonder if the user's problem is more of a "don't do that"
> or something that may be solvable with a libpq or protocol change.
> Basically, the user has a rule which swi
Tom Lane wrote:
By the way, PL/SQL screams if you want to do an assignment with '='.
But I guess that the current behaviour of PL/pgSQL should not reflect
that to maintain backward compatibility, right?
I think it should. The current behaviour is undocumented and more than icky.
Martijn van Oosterhout writes:
> Clever idea, pity we can't use it (what's the bet it's patented?). I'd
> wager anything beyond simple compression is patented by someone.
You're in for a rude awakening: even "simple compression" is anything
but simple. As I said, it's a minefield of patents. I
Now that I've got a little time again...
Per the report from Clark C Evans a while back and associated discussion,
it seems like recent versions of the SQL spec changed the rules for
foreign key column references such that the columns of the referenced
unique constraint must be named in order (th
Alvaro Herrera wrote:
> Cristiano Duarte wrote:
>
>> SQL table aliases doesn't help locating the real place where the table
>> is. If I have a table named "test" at the schema "place" and I do:
>>
>> "EXPLAIN SELECT * FROM place.test mytest"
>>
>> I will get:
>>
>> "Seq Scan on test mytest"
>>
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Albe Laurenz said:
>> ERROR at line 3:
>> ORA-06550: line 3, column 7:
>> PLS-00363: expression 'I' cannot be used as an assignment target
>> ORA-06550: line 3, column 7:
>> PL/SQL: Statement ignored
>>
>> And the documentation also explicitly states
Zdenek Kotala wrote:
> I'm interesting in problem "Allow commenting of variables in
> postgresql.conf to restore them to defaults". And I need some clarify
> of SET command behavior.
>
> Res_value is defined in the source code as highest overriding setting
> during startup (or reconfiguration
I'm interesting in problem "Allow commenting of variables in
postgresql.conf to restore them to defaults". And I need some clarify
of SET command behavior.
Res_value is defined in the source code as highest overriding setting
during startup (or reconfiguration) and it is used for store "defa
The basic issue is that we need to set standard_conforming_strings to
'off' for loading into newer releases, >= 8.2, but that SET command is
going to generate an error even dumping/loading into the same version of
PostgreSQL, like 7.3 to 7.3. I don't think we want that, do we? I agree
we can have
On Wed, May 17, 2006 at 12:45:17PM -, Greg Sabino Mullane wrote:
> Someone posted something on the DBD::Pg mailing list recently that
> made me wonder if the user's problem is more of a "don't do that"
> or something that may be solvable with a libpq or protocol change.
>
> Basically, the user
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Someone posted something on the DBD::Pg mailing list recently that
made me wonder if the user's problem is more of a "don't do that"
or something that may be solvable with a libpq or protocol change.
Basically, the user has a rule which switches an
On 5/17/06, Martijn van Oosterhout wrote:
Clever idea, pity we can't use it (what's the bet it's patented?). I'd
wager anything beyond simple compression is patented by someone.
Oracle's patent application 20040054858 covers the method itself
including the process for storing and retrieving co
> Unfortunatly, the interface provided by pg_lzcompress.c is probably
> insufficient for this purpose. You want to be able to compress tuples
> as they get inserted and start a new block once the output reaches a
I don't think anything that compresses single tuples without context is
going to be
Albe Laurenz said:
> Tom Lane wrote:
>>> It ought to be illegal to modify the loop control variable anyway,
>>> IMNSHO - it certainly is in Ada, the distant antecedent of pl/pgsql.
>>
>> If modifying the loop variable is disallowed in PL/SQL, I'm all for
>> disallowing it in plpgsql, otherwise not.
Ühel kenal päeval, K, 2006-05-17 kell 12:20, kirjutas Zeugswetter
Andreas DCP SD:
> > Certainly, if you can't prototype a convincing performance win using
> > that algorithm, it's unlikely to be worth anyone's time to
> > look harder.
>
> That should be easily possible with LZO. It would need to
> Certainly, if you can't prototype a convincing performance win using
> that algorithm, it's unlikely to be worth anyone's time to
> look harder.
That should be easily possible with LZO. It would need to be the lib
that
we can optionally link to (--with-lzo), since the lib is GPL.
lzo even all
1 - 100 of 106 matches
Mail list logo
