Re: [HACKERS] 8.4 win32 shared memory patch
On Sat, Aug 1, 2009 at 20:30, Kevin Fieldkevinjamesfi...@gmail.com wrote: The event viewer says: The description for Event ID ( 0 ) in Source ( PostgreSQL ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: pg_ctl: could not find postgres program executable And yes, I renamed it correctly... Check permissions on it. If you moved it at some point, it may have the wrong permissions. They should be the same as for the other .EXEs in that directory. The two files (new and old exe) have identical permissions. That's just weird. It could be that the postgres executable won't work - maybe because of some DLL issue. Can you run postgres -V on the executable, or does that give you some error? It reports the version correctly. Sorry...any other ideas? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 win32 shared memory patch
On Fri, Jul 31, 2009 at 19:29, Kevin Fieldkevinjamesfi...@gmail.com wrote: %t LOG: received fast shutdown request %t LOG: aborting any active transactions %t LOG: autovacuum launcher shutting down %t LOG: shutting down %t LOG: database system is shut down That's the entire file. Attempting to start the service, I almost immediately get an error 1067, the process terminated unexpectedly. If there is nothing in the logfile (make sure you're looking at the correct one - it may have created a new one), check the Windows Eventlog. That's where we'll put data if the issues show up before we have started the logger. The event viewer says: The description for Event ID ( 0 ) in Source ( PostgreSQL ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: pg_ctl: could not find postgres program executable And yes, I renamed it correctly... Check permissions on it. If you moved it at some point, it may have the wrong permissions. They should be the same as for the other .EXEs in that directory. The two files (new and old exe) have identical permissions. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 win32 shared memory patch
On Wed, Jul 29, 2009 at 19:52, Kevin Fieldkevinjamesfi...@gmail.com wrote: On Win2k3 Std SP2, the service won't start once I've applied the patch. In the log, I get: %t LOG: CreateProcess call failed: A blocking operation was interrupted by a call to WSACancelBlockingCall. Now, that's just strange :-O First of all, the code from this patch hasn't even executed when that error pops up... So it really shouldn't be that one. Second, that error message just makes no sense in the context. However, the errorcode 2 makes a bit more sense - that's a file not found error. It's still strange that it would show up, but it makes sense in the context of CreateProcess(). Are you sure that there weren't any old processes hanging around when you tried it? Would it be possible for you to test by doing stop - reboot - replace file - start and see if the issue remains? I did this last night as requested. This time, nothing about CreateProcess, perhaps it's a separate issue. All the log said this time was: %t LOG: received fast shutdown request %t LOG: aborting any active transactions %t LOG: autovacuum launcher shutting down %t LOG: shutting down %t LOG: database system is shut down That's the entire file. Attempting to start the service, I almost immediately get an error 1067, the process terminated unexpectedly. Kev -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 win32 shared memory patch
%t LOG: received fast shutdown request %t LOG: aborting any active transactions %t LOG: autovacuum launcher shutting down %t LOG: shutting down %t LOG: database system is shut down That's the entire file. Attempting to start the service, I almost immediately get an error 1067, the process terminated unexpectedly. If there is nothing in the logfile (make sure you're looking at the correct one - it may have created a new one), check the Windows Eventlog. That's where we'll put data if the issues show up before we have started the logger. The event viewer says: The description for Event ID ( 0 ) in Source ( PostgreSQL ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: pg_ctl: could not find postgres program executable And yes, I renamed it correctly... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 8.4 win32 shared memory patch
On Win2k3 Std SP2, the service won't start once I've applied the patch. In the log, I get: %t LOG: CreateProcess call failed: A blocking operation was interrupted by a call to WSACancelBlockingCall. (error code 2) %t LOG: could not fork autovacuum worker process: A blocking operation was interrupted by a call to WSACancelBlockingCall. [ and then 47k worth of that whole message repeated, and then: ] %t LOG: received fast shutdown request %t LOG: aborting any active transactions %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t FATAL: terminating connection due to administrator command %t LOG: autovacuum launcher shutting down %t FATAL: terminating connection due to administrator command %t LOG: shutting down %t LOG: database system is shut down (BTW, I noticed the %t everywhere in all of my 8.4 logs, whereas in my 8.3 logs there're actual timestamps instead. Bug?) I put the old binary back and it works fine. Cheers, Kev -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 win32 shared memory patch
I put the old binary back and it works fine. For the record, fine meaning I've never had the shared memory problem. Kev -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP
On May 29, 1:04 pm, t...@sss.pgh.pa.us (Tom Lane) wrote: Kevin Field kevinjamesfi...@gmail.com writes: default: elog(ERROR, unrecognized raise option: %d, opt-opt_type); Should this be changed to: default: ereport(ERROR, (errmsg_internal(unrecognized raise option: %d, opt-opt_type))); No, we generally don't bother with that. The above two are exactly equivalent and the first is easier to write, so why complicate the code? ereport is needed if you want to specify a SQLSTATE, provide a translatable error message, etc, but for internal shouldn't-happen cases we customarily just use elog. Ah, I had missed that. I understand. The function's comment's still out of date though, I think, since it uses ereport at the end. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP
On May 29, 12:43 pm, Kevin Field kevinjamesfi...@gmail.com wrote: On May 29, 11:48 am, Kevin Field kevinjamesfi...@gmail.com wrote: On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote: On Fri, May 29, 2009 at 7:59 AM, Kevin Field kevinjamesfi...@gmail.com wrote: On May 28, 5:19 pm, da...@kineticode.com (David E. Wheeler) wrote: On May 28, 2009, at 12:53 PM, Kevin Field wrote: Can pgTap check for a regex instead if just a string? That's the other option, if the pgTAP author is willing...if the SQLSTATE thing doesn't work out I guess we'll have to go down that road. Patches welcome. ;-) http://github.com/theory/pgtap/tree/master/ I'm getting a new version ready to release as I type. Thanks, great to know. :) Although, I do think changing plperl is the more proper option, so I'm going to try there first... It seems to me that removing line numbers from PL/perl error messages is not a good solution to anything. Line numbers are extremely useful for debugging purposes, and getting rid of them because one particular testing framework doesn't know how to use regular expressions is solving the wrong problem. You're right, but that's not what I'm proposing... I'm also a bit confused because your original post had a line number in the PL/pgsql output, too, just formatted slightly differently. Why doesn't that one cause a problem? The difference is, in PL/pgsql they're in the CONTEXT: line, whereas in plperl they're in the error line. This is inconsistent; if we fix it, we don't need to add kludge to pgTAP. But later in the thread the desired fix became not changing perl but instead making a way to report error codes from plperl, which is what I'm attempting to do with my rusty C skills soon. plperl should have ereport() *anyway*, as I believe Tom had insinuated. Hmm, I'm rustier than I thought. I might need some help with this later. Actually, I'm not sure I'll be able to be of any use on this after all. Would someone be able to add plperl ereport to the todo list for me at least? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP
On May 28, 5:19 pm, da...@kineticode.com (David E. Wheeler) wrote: On May 28, 2009, at 12:53 PM, Kevin Field wrote: Can pgTap check for a regex instead if just a string? That's the other option, if the pgTAP author is willing...if the SQLSTATE thing doesn't work out I guess we'll have to go down that road. Patches welcome. ;-) http://github.com/theory/pgtap/tree/master/ I'm getting a new version ready to release as I type. Thanks, great to know. :) Although, I do think changing plperl is the more proper option, so I'm going to try there first... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP
On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote: On Fri, May 29, 2009 at 7:59 AM, Kevin Field kevinjamesfi...@gmail.com wrote: On May 28, 5:19 pm, da...@kineticode.com (David E. Wheeler) wrote: On May 28, 2009, at 12:53 PM, Kevin Field wrote: Can pgTap check for a regex instead if just a string? That's the other option, if the pgTAP author is willing...if the SQLSTATE thing doesn't work out I guess we'll have to go down that road. Patches welcome. ;-) http://github.com/theory/pgtap/tree/master/ I'm getting a new version ready to release as I type. Thanks, great to know. :) Although, I do think changing plperl is the more proper option, so I'm going to try there first... It seems to me that removing line numbers from PL/perl error messages is not a good solution to anything. Line numbers are extremely useful for debugging purposes, and getting rid of them because one particular testing framework doesn't know how to use regular expressions is solving the wrong problem. You're right, but that's not what I'm proposing... I'm also a bit confused because your original post had a line number in the PL/pgsql output, too, just formatted slightly differently. Why doesn't that one cause a problem? The difference is, in PL/pgsql they're in the CONTEXT: line, whereas in plperl they're in the error line. This is inconsistent; if we fix it, we don't need to add kludge to pgTAP. But later in the thread the desired fix became not changing perl but instead making a way to report error codes from plperl, which is what I'm attempting to do with my rusty C skills soon. plperl should have ereport() *anyway*, as I believe Tom had insinuated. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP
On May 29, 11:48 am, Kevin Field kevinjamesfi...@gmail.com wrote: On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote: On Fri, May 29, 2009 at 7:59 AM, Kevin Field kevinjamesfi...@gmail.com wrote: On May 28, 5:19 pm, da...@kineticode.com (David E. Wheeler) wrote: On May 28, 2009, at 12:53 PM, Kevin Field wrote: Can pgTap check for a regex instead if just a string? That's the other option, if the pgTAP author is willing...if the SQLSTATE thing doesn't work out I guess we'll have to go down that road. Patches welcome. ;-) http://github.com/theory/pgtap/tree/master/ I'm getting a new version ready to release as I type. Thanks, great to know. :) Although, I do think changing plperl is the more proper option, so I'm going to try there first... It seems to me that removing line numbers from PL/perl error messages is not a good solution to anything. Line numbers are extremely useful for debugging purposes, and getting rid of them because one particular testing framework doesn't know how to use regular expressions is solving the wrong problem. You're right, but that's not what I'm proposing... I'm also a bit confused because your original post had a line number in the PL/pgsql output, too, just formatted slightly differently. Why doesn't that one cause a problem? The difference is, in PL/pgsql they're in the CONTEXT: line, whereas in plperl they're in the error line. This is inconsistent; if we fix it, we don't need to add kludge to pgTAP. But later in the thread the desired fix became not changing perl but instead making a way to report error codes from plperl, which is what I'm attempting to do with my rusty C skills soon. plperl should have ereport() *anyway*, as I believe Tom had insinuated. BTW, I noticed in exec_stmt_raise() in src/pl/plpgsql/src/pl_exec.c that the comment still says throw it with elog() rather than ereport () even though ereport() is used in all places but one in the function: default: elog(ERROR, unrecognized raise option: %d, opt-opt_type); Should this be changed to: default: ereport(ERROR, (errmsg_internal(unrecognized raise option: %d, opt-opt_type))); ...along with the comment? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP
On May 29, 11:48 am, Kevin Field kevinjamesfi...@gmail.com wrote: On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote: On Fri, May 29, 2009 at 7:59 AM, Kevin Field kevinjamesfi...@gmail.com wrote: On May 28, 5:19 pm, da...@kineticode.com (David E. Wheeler) wrote: On May 28, 2009, at 12:53 PM, Kevin Field wrote: Can pgTap check for a regex instead if just a string? That's the other option, if the pgTAP author is willing...if the SQLSTATE thing doesn't work out I guess we'll have to go down that road. Patches welcome. ;-) http://github.com/theory/pgtap/tree/master/ I'm getting a new version ready to release as I type. Thanks, great to know. :) Although, I do think changing plperl is the more proper option, so I'm going to try there first... It seems to me that removing line numbers from PL/perl error messages is not a good solution to anything. Line numbers are extremely useful for debugging purposes, and getting rid of them because one particular testing framework doesn't know how to use regular expressions is solving the wrong problem. You're right, but that's not what I'm proposing... I'm also a bit confused because your original post had a line number in the PL/pgsql output, too, just formatted slightly differently. Why doesn't that one cause a problem? The difference is, in PL/pgsql they're in the CONTEXT: line, whereas in plperl they're in the error line. This is inconsistent; if we fix it, we don't need to add kludge to pgTAP. But later in the thread the desired fix became not changing perl but instead making a way to report error codes from plperl, which is what I'm attempting to do with my rusty C skills soon. plperl should have ereport() *anyway*, as I believe Tom had insinuated. Hmm, I'm rustier than I thought. I might need some help with this later. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] plperl error format vs plpgsql error format vs pgTAP
I use pgTAP to make sure my functions produce the correct errors using throws_ok(). So when I get an error from a plpgsql function, it looks like this: ERROR: upper bound of FOR loop cannot be null CONTEXT: PL/pgSQL function foo line 35 at FOR with integer loop variable ...which I can then test using throws_ok by giving it the string 'upper bound of FOR loop cannot be null'. However, in a plperl function, errors come out in this format: error from Perl function check_no_loop: Loops not allowed! Node 1 cannot be part of node 3 at line 13. Unfortunately, I can't test for this without including the line number, which means that changing any plperl function that I have such a test for pretty much guarantees that I'll need to change the test to reflect the new line numbers the errors would be thrown from in the function. Is it possible to unify the error reporting format, so pgTAP can test them without needing line numbers from plperl functions? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP
On May 28, 3:22 pm, t...@sss.pgh.pa.us (Tom Lane) wrote: Kevin Field kevinjamesfi...@gmail.com writes: I use pgTAP to make sure my functions produce the correct errors using throws_ok(). So when I get an error from a plpgsql function, it looks like this: ERROR: upper bound of FOR loop cannot be null CONTEXT: PL/pgSQL function foo line 35 at FOR with integer loop variable ...which I can then test using throws_ok by giving it the string 'upper bound of FOR loop cannot be null'. Surely, this is a completely brain-dead approach to testing errors in the first place ... what will happen in a localized installation? What you need is a test that looks at the SQLSTATE code, and little if anything else. There won't be any localized installations. I wanted to use the SQLSTATE code, but it's always XX000. If there were some way to set it when calling elog() so I knew the right error was being reached, that would be a great option. Is that something under the control of PostgreSQL? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP
On May 28, 3:28 pm, and...@dunslane.net (Andrew Dunstan) wrote: Kevin Field wrote: I use pgTAP to make sure my functions produce the correct errors using throws_ok(). So when I get an error from a plpgsql function, it looks like this: ERROR: upper bound of FOR loop cannot be null CONTEXT: PL/pgSQL function foo line 35 at FOR with integer loop variable ...which I can then test using throws_ok by giving it the string 'upper bound of FOR loop cannot be null'. However, in a plperl function, errors come out in this format: error from Perl function check_no_loop: Loops not allowed! Node 1 cannot be part of node 3 at line 13. Unfortunately, I can't test for this without including the line number, which means that changing any plperl function that I have such a test for pretty much guarantees that I'll need to change the test to reflect the new line numbers the errors would be thrown from in the function. Is it possible to unify the error reporting format, so pgTAP can test them without needing line numbers from plperl functions? This is under perl's control, not ours. The perl docco says: If the last element of LIST does not end in a newline, the current script line number and input line number (if any) are also printed and a newline is supplied. Can pgTap check for a regex instead if just a string? That's the other option, if the pgTAP author is willing...if the SQLSTATE thing doesn't work out I guess we'll have to go down that road. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_views definition format
On May 13, 5:37 pm, gsm...@gregsmith.com (Greg Smith) wrote:
On Wed, 13 May 2009, Kevin Field wrote:
Or would the only way to do this be to actually create a view and then
call pg_get_viewdef() and then delete the view?
Just make it a temporary view and then it drops when the session ends.
Here's a working shell example that transforms a view into the parsed form
and returns it:
$ v=select * from pg_views
$ p=`psql -Atc create temporary view x as ${v}; select
pg_get_viewdef('x'::regclass);`
$ echo $p
SELECT pg_views.schemaname, pg_views.viewname, pg_views.viewowner,
pg_views.definition FROM pg_views;
Thanks. This works more quickly than I thought it might, which is
good.
Something I ran into though when trying to extend this logic to rules:
for some reason rule definitions are compiled with create rule x as
in front of them, unlike views, which just have everything after the
as. I can keep the two parts separate and test accordingly, but it
seems a bit inconsistent.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_rules definition format
On May 14, 2:22 pm, Kevin Field kevinjamesfi...@gmail.com wrote: Something I ran into though when trying to extend this logic to rules: for some reason rule definitions are compiled with create rule x as in front of them, unlike views, which just have everything after the as. I can keep the two parts separate and test accordingly, but it seems a bit inconsistent. The fix isn't actually this clean in the end, since the 'fake' rule to be returned will have a different 'definition' (because its name is different) than the one we'd actually use to insert. So either we do some regexing or we have to back up the old rule's definition, drop the rule, insert it, get the new definiton, compare, and then if they're different, drop it again and put the old one back. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_rules definition format
On May 14, 2:22 pm, Kevin Field kevinjamesfi...@gmail.com wrote: Something I ran into though when trying to extend this logic to rules: for some reason rule definitions are compiled with create rule x as in front of them, unlike views, which just have everything after the as. I can keep the two parts separate and test accordingly, but it seems a bit inconsistent. The fix isn't actually this clean in the end, since the 'fake' rule to be returned will have a different 'definition' (because its name is different) than the one we'd actually use to insert. So either we do some regexing or we have to back up the old rule's definition, drop the rule, insert it, get the new definiton, compare, and then if they're different, drop it again and put the old one back. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_views definition format
On May 13, 11:31 am, Kev kevinjamesfi...@gmail.com wrote: Hi, I have a script that automatically generates the SQL to create some views. I'd like it to check whether its generated SQL matches the SQL returned by select definition from pg_views where I've guessed most of the rules just by looking at the output, but I was surprised to find that some of my views of the form: select.from b left join a on a.id=b.id ...were being translated to this: SELECT..FROM (B LEFT JOIN a ON ((a.id = b.id))) ...before being stored in the table pg_views is derived from. My surprise is at the double parentheses around a.id = b.id. Is that supposed to be that way? Is it likely to change? Thanks, Kev One other thing I'm just curious about, != gets replaced with ...how come? (Feels more VB-ish than C-ish, so I was surprised that that would be the official/preferred reconstruct) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_views definition format
On May 13, 12:41 pm, kevin.gritt...@wicourts.gov (Kevin Grittner) wrote: Kevin Field kevinjamesfi...@gmail.com wrote: One other thing I'm just curious about, != gets replaced with ...how come? (Feels more VB-ish than C-ish, so I was surprised that that would be the official/preferred reconstruct) is the SQL standard operator. != is a PostgreSQL extension, for the convenience and comfort of those more used to it. Ahh, that makes sense. Thanks, guys. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_views definition format
On May 13, 12:52 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
Kev kevinjamesfi...@gmail.com writes:
... I was surprised
to find that some of my views of the form:
select.from b left join a on a.id=b.id
...were being translated to this:
SELECT..FROM (B LEFT JOIN a ON ((a.id = b.id)))
...before being stored in the table pg_views is derived from. My
surprise is at the double parentheses around a.id = b.id. Is that
supposed to be that way? Is it likely to change?
There isn't any such table. What pg_views is showing you is a reverse
compilation of the internal parsetree for the rule. Whether there are
parentheses in a given place is dependent on whether the code thinks it
might be safe to omit them ... and I think in the non-prettyprinted
format the answer is always no. For instance with pg_views itself:
regression=# select pg_get_viewdef('pg_views'::regclass);
pg_get_viewdef
SELECT n.nspname AS schemaname, c.relname AS viewname,
pg_get_userbyid(c.relowner) AS viewowner, pg_get_viewdef(c.oid) AS definition
FROM (pg_class c LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace)))
WHERE (c.relkind = 'v'::char);
(1 row)
regression=# select pg_get_viewdef('pg_views'::regclass, true);
pg_get_viewdef
---
SELECT n.nspname AS schemaname, c.relname AS viewname,
pg_get_userbyid(c.relowner) AS viewowner, pg_get_viewdef(c.oid) AS definition
FROM pg_class c
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'v'::char;
(1 row)
Same parsetree, but the latter case is working a bit harder to make
it look nice. The default case is overparenthesizing intentionally
to make dead certain the rule will be parsed the same way if it's
dumped and reloaded.
regards, tom lane
That's handy to know about pg_views. I'm still not sure how I should
code my script to make it future-proof though (because things of the
form ((a)) seem beyond dead-certain...) unless...is there some
function I can call to parse and then recompile the SQL, so I can feed
in my generated code in any format I like and then have it translate?
Or would the only way to do this be to actually create a view and then
call pg_get_viewdef() and then delete the view?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgres SQL specification (tests)
On Apr 16, 10:52 am, mito milos.ors...@gmail.com wrote: By table structure i mean table definition options. ...which includes columns, right? Sorry, I don't think I can picture what you're trying to do. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Postgres SQL specification (tests)
On Apr 16, 3:14 am, mito milos.ors...@gmail.com wrote: Hi, i have built an SQL interface using rule system which supports row versioning and i would like to test it against Postgres SQL specification. Is there something like test cases for postgres SQL interface? Or do you have any ideas how to build a group of all possible cases of table structure and generate appropriate queries, which can be tested against postgres? thanks For unit testing, I use pgTap, it's pretty handy for scripting your tests. What do you mean by all possible cases of table structure? That would be infinite... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql debugger (pldbg) absent from 8.4?
I'll see if I can get an updated build pushed out sometime today. I finally got around to trying this out using the March 24th build, and it has the same issue... Kev -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql debugger (pldbg) absent from 8.4?
On Apr 8, 10:32 am, dp...@pgadmin.org (Dave Page) wrote: On Wed, Apr 8, 2009 at 2:48 PM, Kevin Field kevinjamesfi...@gmail.com wrote: I'll see if I can get an updated build pushed out sometime today. I finally got around to trying this out using the March 24th build, and it has the same issue... I just installed it here on a clean VM and I see the docs, the SQL script and all the right libraries. What are you missing? Well, the 2 DLLs are there, and actually, the SQL file is too, so I ran it, and it complained about types already existing, so I took out each of those and retried until all that were left were the CREATE OR REPLACE FUNCTION lines, and those ran successfully. But then I got the same error again when actually trying to do Set Breakpoint in pgAdmin. What else would I check for? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] plpgsql debugger (pldbg) absent from 8.4?
On Apr 8, 11:26 am, dp...@pgadmin.org (Dave Page) wrote: Did you add shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll' to postgresql.conf and restart the server per the README? Oh my goodness. No. Thank you so much. It works fine now. I'll have to add that to my upgrading procedure... Kev -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
