Re: [HACKERS] 8.4 win32 shared memory patch
> On Sat, Aug 1, 2009 at 20:30, Kevin Field > 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 Field > 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
> > %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
Re: [HACKERS] 8.4 win32 shared memory patch
> On Wed, Jul 29, 2009 at 19:52, Kevin Field > 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
> 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
[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] plperl error format vs plpgsql error format vs pgTAP
On May 29, 12:43 pm, Kevin Field wrote:
> On May 29, 11:48 am, Kevin Field wrote:
>
>
>
> > On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
>
> > > On Fri, May 29, 2009 at 7:59 AM, Kevin Field
> > > 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 29, 1:04 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
> Kevin Field 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, 11:48 am, Kevin Field wrote:
> On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
>
>
>
> > On Fri, May 29, 2009 at 7:59 AM, Kevin Field
> > 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
Re: [HACKERS] plperl error format vs plpgsql error format vs pgTAP
On May 29, 11:48 am, Kevin Field wrote:
> On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
>
>
>
> > On Fri, May 29, 2009 at 7:59 AM, Kevin Field
> > 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:35 am, robertmh...@gmail.com (Robert Haas) wrote:
> On Fri, May 29, 2009 at 7:59 AM, Kevin Field
> 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 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 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] 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 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
[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] pg_rules definition format
On May 14, 2:22 pm, Kevin Field 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 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, 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_views definition format
On May 13, 12:52 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
> Kev 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] pg_views definition format
On May 13, 12:41 pm, kevin.gritt...@wicourts.gov ("Kevin Grittner")
wrote:
> Kevin Field 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, 11:31 am, Kev 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] Postgres SQL specification (tests)
On Apr 16, 10:52 am, mito 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 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?
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
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 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?
> 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
