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. Anyone have a
> recen
Just a small example of the fact that people need such
functionality... and will devise other ways, albeit inefficient and
dangerous, to implement the missing feature.
The success of an RDBMS (or any other product for that matter)
depends on how well it strikes the balance between the stand
Andrew Piskorski wrote:
>>> Rod Taylor wrote:
Disk storage is cheap. Disk bandwidth or throughput is very
expensive.
>
> Oracle has included "table compression" since 9iR2. They report table
> size reductions of 2x to 4x as typical, with proportional reductions
> in I/O, and supposedly, usual
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 table entries (of that block).
> - This lookup table is referenced from within t
On Wed, May 17, 2006 at 12:03:15AM -0400, Tom Lane wrote:
> AFAICS the only sane choice here is to use
> src/backend/utils/adt/pg_lzcompress.c, on the grounds that (1) it's
> already in the backend, and (2) data compression in general is such a
> minefield of patents that we'd be foolish to expose
On Tue, May 16, 2006 at 11:48:21PM -0400, Greg Stark wrote:
> There are some very fast decompression algorithms:
>
> http://www.oberhumer.com/opensource/lzo/
Sure, and for some tasks in PostgreSQL perhaps it would be useful.
But at least as of July 2005, a Sandor Heman, one of the MonetDB guys,
> 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
Ü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
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.
> 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
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
-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 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
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
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
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
"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
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"
>>
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
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
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.
"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
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
""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
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.
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
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
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,
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
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 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
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 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
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 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 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
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
> 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
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
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?
"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
> > 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
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
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
"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, 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
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
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
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
> 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
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
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
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
"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
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
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
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
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
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.
>>
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
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
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" <[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
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
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
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 -->
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
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
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
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 "
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
"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
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
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
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
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
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
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
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
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
Ü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
Ü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
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 -->
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
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
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
Ü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.
> >>
>
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
"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
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
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
Ü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
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.
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
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
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
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/
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,
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
1 - 100 of 106 matches
Mail list logo
